Hi,
I'm trying to get a handle on how threads are being used in 1.9.16-SNAPSHOT
(svn r3170). I currently have two areas of outstanding questions.
1) I see leader-follower strategy. When in use, a worker thread from the
controller's threadpool is used for the SelectorHandlerRunner. When a
selected event occurs, delegateToWorker branch of
SelectorHandler.handleSelectedKey, the current thread requests another
thread to become the selector thread, and handles the key processing itself,
returning itself to the thread pool on completion. This is different from a
strategy where the selector thread requests another thread to do the key
processing, and retains the role as selector thread. Is this correctt? Is
this strategy effective if there is more than one selector key (event) to
process? or, under what conditions is this strategy ineffective/effective?
2) I see that Controller.autoConfigure sizes readThreadsCount (by the number
of processors). This value is used later in Controller.start to create a
RoundRobinSelectorHandler; for each of readThreadsCount, a ReadContoller is
created. When acceptInterest occurs, RoundRobinSelectorHandler will pick
one of the ReadControllers and assign the selected channel to it. Each
ReadController runs its own SelectorHandler thread, and so, selection work
is distributed across a group of threads (sized by the number of
processors). It looks like this action of distributing selection across
threads will only be activated onAcceptInterest, and in cases where a server
does not bind, this won't occur. Is that correct? In absence of
onAcceptInterest callbacks (no binding), can selection work be distributed
across threads?
Thanks,
John