On 11/7/06, Robert Greig <[EMAIL PROTECTED]> wrote:
On 06/11/06, Vinod Panicker <[EMAIL PROTECTED]> wrote: > The rationale is fine, but does the multi-threaded SocketIoProcessor > use a thread pool or just two threads? No it does not use a pool. It uses two threads per SocketIoProcessor where currently it uses one. > > The obvious solution is to limit the number of writes done in a given > > loop but this then leads to throughput reduction. After much messing > > about we found that using two threads allows reads and writes to run > > "flat out" as much as possible. > > Wouldn't the bias be applicable for reads as well? It sounds like a > case of inertia unless I'm missing something. Reads were handled differently in the original code, it just reads enough up to the size of the buffer.
I see. Your device is flushing the write buffer blazingly fast so the write loop doesn't finish soon enough when a lot of data is in the write queue. That makes sense. Then what do you think about limiting the amount of data written per session per loop instead of using two threads? I think we need to compare the modified version of SocketIoProcessor and the MultiSocketIoProcessor. Trustin -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
