Thanks for your effort. I have not looked at your changes yet, but
would like to examine your assumptions here.
Nothing prevents anyone from creating multiple NioSelectorScheduler
instances (hence multiple selector threads) each of which manages its
own set of tasks, just like any scheduler, and its own set of sockets.
The one part I have not implemented is transparent migration of a task
from one NioSelector to another, because that would entail
deregistration from one first. But the intention has always been to
support any number of NioSelectorSchedulers.
I'd love to hear from you where you think this is limited.
Thanks.
--sriram.