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