directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@realityforge.org>
Subject Re: Serverside NIO: Not ready for Prime Time
Date Wed, 26 Nov 2003 03:00:27 GMT
On Wed, 26 Nov 2003 12:37 pm, Geir Magnusson Jr wrote:
> Ye gads.  Why can't you multithread the reads?  What possible reason
> could one come up with that the reads have to happen on the same thread
> as the select?

Because it doesn't work ;) 

I could offer a reasonable explanation of why that is so but ultimately it 
comes down to the fact that the underlying OSes are inconsistent - 
particularly when there is multiple CPUs. The java layers on top proably 
introduce more ways in which sligt differences can occur. 

Consider the scenario

CPU1 returns Select with FD3

> > See attached files for the sort of thing I mean. Associated with each
> > connection object I have a TcpTransport object. The selector threads
> > does all
> > the nbio and then sends event to "parsing" stage. This seems to work
> > like a
> > charm.
>
> Don't that serialize the I/O?

Not sure what you mean. It is a little bit "unfair" because usually the 
SelectorKeys are returned in order of underlying FDs and thus channels early 
in the set are always early in the set. But as long as you randomizethe 
processing order this should not be an issue.

As long as you dont do memory allocation in selector thread then all that 
thread does is select() and memcpy() which can scale relatively well even if 
you batch it and randomize events when you pass them o0nto next stage.

-- 
Cheers,

Peter Donald
*-----------------------------------------------------*
| Never argue with an idiot, they'll drag you down to |
| their level, and beat you with experience           |
*-----------------------------------------------------* 


Mime
View raw message