On 2/26/2015 7:23 AM, Eric Covener wrote: > You might check out how mod_spdy shares a connection between threads.
Hi Eric, thanks for the suggestion! mod_spdy is interesting; IIUC, the logic is basically output_block_time = 1 ms while (not stopped) { // Input cycle if no output is possible: block to read data else: read as much data as we have without blocking if we got data: process the data reset output_block_time to 1 ms // Output cycle if output is possible: wait up to <output_block_time> for output if we have output: write it to socket (blocking) else: output_block_time *= 2, max out at 30 ms } I'm assuming this approach was taken because SPDY is still (I think) request-response based. For WebSocket, output is _always_ possible at any time, which means we would never get to perform the "block to read data" step. We'd have to introduce a maximum blocking time for input too, so an idle-but-connected WebSocket would continually bounce between waiting on input and waiting on output. The exponential backoff helps, but the somewhat random spikes in latency mean it's definitely not my first choice. I'm interested in the TODO at the bottom of that block though: mod_spdy/common/spdy_session.cc:191: > TODO(mdsteele): What we really want to be able to do is to block > until *either* more input or more output is available. Unfortunely, > there's no good way to query the input side (in Apache). One > possibility would be to grab the input socket object (which we can > do), and then arrange to block until either the socket is ready to > read OR our output queue is nonempty (obviously we would abstract > that away in SpdySessionIO), but there's not even a nice way to do > that (that I know of). In this case, if I can get the input socket, I might be able to construct an APR_POLLSET_WAKEABLE pollset around it, and use apr_pollset_wakeup() to break out of the poll whenever I want to write output. I'm currently failing to find how to get a socket from a request_rec, though. I'm guessing it's not supposed to be easy... Jacob Champion LabVIEW R&D National Instruments