I'll let JF comment on the configuration capabilities in Grizzly 1.5.
In Grizzly 2.0 we were allowing configuration of one or more Selectors.
However, one would always handle accept events. Additional Selectors
would handle read events. And, there were temporary Selectors as well.
The use of temporary Selectors are also an attempt to minimize the
number of context switches.
One configuration I've been considering for a small number of
connections is a dedicated Selector per connection, yet still do
non-blocking reads. This configuration would be very similar to what
you are suggesting. I can further explain on today's call.
In such a configuration, as I've been thinking, I'm a little concerned
about the number of Selector objects when the number of connections is
really large.
charlie ....
Harold Carr wrote:
> Hello all,
>
> It is generally thought that context switching is expensive and should
> be avoided. Does anyone have any current performance measurements in
> this area on multicore machines?
>
> The leader/follower pattern is an attempt to minimize context
> switching. Leader/follower is easy to think about in a
> ReaderThread/WorkerThread implementation:
>
> 1. The ReaderThread blocks waiting for input.
> 2. When input arrives the ReaderThread morphs to a WorkerThread and a
> new/pooled thread takes over the ReaderThread role.
>
> But how does this pattern fit a SelectorThread/WorkerThread
> implementation?
>
> When the SelectorThread unblocks it might unblock with *several*
> events, so it just can't morph into a WorkerThread --- there is work
> for each event, and some events might be short and done by the
> SelectorThread while others need a true WorkerThread.
>
> I suppose if there is only one event and that event needs its own
> thread, then the SelectorThread could morph into a WorkerThread and a
> new/pooled thread would take over as Selector.
>
> Would the above even be worth it?
>
> What does Grizzly do at this time?
>
> Regards,
> Harold
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>