Salut,
ming qin wrote:
> Hi Everyone:
>
> After examining a few classes in Grizzly 1.5.0 and Grizzly 1.9.X
> such as Controller( initReadThread(), copyto() ), Cloner ( clone()) ,
> TCPSelectHandler, WorkerThreadImpl, RoundRobinSelectorHandler and
> Controller’s shallow copy on TCPSelectorHandler’s selector property to
> ReadController ), my impression is that Grizzly’s selector design was
> aligned with Ron’s recommendation on having single selector.
Not sure who came with the idea first :-) Usually you should have one
acceptor(Selector) per core, not more. This is what we came with a
couple of years ago.
>
>
>
> Is my conclusion right? How does grizzly 2.o handle this issue (
> multiple selectors vs. single selector)
Should be supported as well.
A+
-- Jeanfrancois
>
>
>
> See below Ron’s recommendation on this subject
>
>
>
> Ron Hitchens ( his 2002 book <<Java NIO>> chapter 4 section 5 –
> Selection Scaling) argued that “A better approach is to use one selector
> for all selectable channels and delegate the servicing of ready channels
> to other threads. You have a single point to monitor channel readiness
> and a decoupled pool of worker threads to handle the incoming data. The
> thread pool size can be tuned (or tune itself, dynamically) according to
> deployment conditions. Management of selectable channels remains simple,
> and simple is good.”
>
>
>
>
> Ming Qin
> Cell Phone 858-353-2839
>
> -
>