On 07/11/06, Trustin Lee <[EMAIL PROTECTED]> wrote:
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
I think if you couple a read limit with a similar maximum read amount
per session per loop then it will be closer, but I'm not sure it will
match the multithreaded approach for throughput, when you have
sufficient CPUs to run the threads.
--
Martin Ritchie
