- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 5 Aug 2013 07:20:36 +0200
- To: Steve Davis <steven.charles.davis@gmail.com>
- Cc: Fred Akalin <akalin@google.com>, HTTP Working Group <ietf-http-wg@w3.org>, Roberto Peon <grmocg@gmail.com>
On 4 August 2013 19:38, Steve Davis <steven.charles.davis@gmail.com> wrote: > It rather looks like I missed the fact that the frame decode/encode has to > be done sequentially to reconstruct the request before passing it to/from > the relevant stream process. That's the safe way. Ultimately, there will be a single thread that sequences writes into the TCP stream, so there's limited gain from concurrent processing for compression. That said, you might be able to come up with a clever scheme that allows multiple threads to do the bulk of the compression logic concurrently. I'm not sure that it would be worthwhile at this early stage, however, because it's unlikely to give any significant gains in contrast, though it certainly would be a complex piece of code that probably wouldn't survive changes. As I understand it, the current spec isn't highly likely to be the final one.
Received on Monday, 5 August 2013 05:21:03 UTC