Callback Based Selectors
David Lloyd
david.lloyd at redhat.com
Mon Mar 19 16:12:29 UTC 2018
On Mon, Mar 19, 2018 at 10:57 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
>
> Is it a concern that the new method opens the door to invite people start to
> write
> "processing code" inside "selecting" operation? which is different use model
> compared
> to the existing one.
I don't think that's necessarily a bad thing. For example it could be
perfectly reasonable to accept connections or perform simple UDP
request processing in a callback. Given the lack of locking the key
sets in this case, my queue approach might even become obsolete, which
would be ideal from my perspective.
> It's fine if the only thing the passed in "consumer"
> does is to simply
> add the SelectionKey into a queue for later process, as David intends to do.
> Or even go
> a little further to create a task and submit into some executor, but it
> might start to
> be an issue if the "consumer" starts to read couple byes from the io or even
> worse
> if the io is in blocking mode ...
Channels in blocking mode won't be registered in a selector,
hopefully. Our frameworks at least keep all channels in non-blocking
mode and use temporary selectors to simulate blocking behavior. But I
guess your point is that applications would need to be cognizant of
the fact that the selector lock would be held for the duration of the
selection operation. I don't think that this specifically is a
serious problem though.
> It appears the original motivation is to help the performance of handling
> those keys,
> but seems it is kinda of trade off of the "select" throughput . The
> "select()" is now being
> blocked till the consumer is applied/accepted for all selected keys, and if
> we are having
> a long list of "ready" keys then you might want to ask if it's a worthy
> tradeoff.
>
> For David's use scenario, a more straightforward method might be better?
>
> int select(Queue<SelectionKey> q, long timeout);
Users who want to process on select will just write a really ugly
Queue implementation which maps all "add" operations to their
processing routine. IMO it's better for the API to avoid artificial
restrictions and stick with the best mapping - in this case the best
mapping would be a consumer of some sort (though I think an argument
could possibly be made for allowing the callback interface to be able
to throw IOException).
> But I doubt it brings big difference as calling selectedKeys() after
> select() :-)
>
> I'm sure the proposed method has its own use case. But it might be worth
> some more
> words against the "inappropriate" usage.
I agree that admonitions against misuse are a good idea.
--
- DML
More information about the nio-dev
mailing list