Callback Based Selectors

Xueming Shen xueming.shen at oracle.com
Mon Mar 19 15:57:59 UTC 2018


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. 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 ...

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);

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.

Sherman

it appears the new method opens the door to invite people to write the 
code to
process the "key" during selecting.

On 3/14/18, 7:05 AM, Alan Bateman wrote:
> On 16/01/2016 11:14, Richard Warburton wrote:
>> Hi gents,
>>
>> I've prototyped a callback based addition to the NIO Selector, which 
>> I've previously talked through a bit with Alan Bateman. The goal of 
>> the callback based selector is to avoid the current pattern of 
>> calling select/selectNow on a Nio selector and then having to iterate 
>> over a hashmap produced. This pattern being quite object allocation 
>> heavy for a critical path and also involving obtaining and releasing 
>> multiple locks. I'd like to propose that the following patch, which 
>> adds the ability to perform a select on a Selector that takes a 
>> callback handler.
>>
>> http://cr.openjdk.java.net/~rwarburton/select-now-4/ 
>> <http://cr.openjdk.java.net/%7Erwarburton/select-now-4/>
>>
>> I'm happy to iterate on the patch a bit based upon people's feedback 
>> and discuss any potential concerns or issues that you may have with 
>> the patch. Looking forward to hearing your feedback.
>>
> This one has been on my list for a long time to study more closely. 
> When we discussed it here in 2016 I had concerns about invoking a 
> consumer while synchronized on the selector and other locks. It has 
> grown on my a bit so I spent a bit of time recently to work through 
> the  implications, both spec and implementation.
>
> For the spec:  The Selector API describes selection operations in its 
> class description and it's important to keep that consistent when 
> introducing a new way to be notified of channels ready for I/O operations.
>
> The action is arbitrary code and we have to assume it will behave as 
> if it's a bull in a china shop. It might attempt another selection 
> operation on the same selector, it might close the selector, it might 
> change the interest set or cancel a key for a channel registered with 
> the selector but not yet seen by the consumer. All of these scenarios 
> need consideration.
>
> Locking was mostly ignored in the original prototype but the locking 
> has to be consistent with how the existing selection operations are 
> specified. The main reason is processing the cancelled-key set means 
> removing keys from the key set and selected-key set. On the surface, 
> the new methods should not care about the selected-key set but they 
> have to maintain the invariant that the selected-key set is always a 
> subset of the selector's key set.
>
> Another point of detail is that the action may need to be called more 
> than once for the same key but different ready sets. We have this with 
> the kqueue implementation where events for read and write are 
> registered with different filters. Other implementation might maintain 
> separate poll arrays for read and write events.
>
> In terms of performance, the main benefit is that avoids adding keys 
> to the selected-key set, only to be removed almost immediately by the 
> code doing the select. This avoids garbage so helps the GC too. If we 
> go ahead with these methods then it's important to get a good range of 
> performance data and also see whether a specialized set to support the 
> usage pattern of the selected-key set might be alternative to 
> introducing new APIs.
>
> I've put a webrev here with candidate changes to the Selector API. 
> It's one select(Consumer<SelectionKey>, timeout) for now, the 
> select(Consumer<SelectionKey>) and selectNow(Consumer<SelectionKey>) 
> variants are easy to add if needed. The webrev has a default 
> implementation based on the existing API, and then implementations for 
> macOS and Linux. Other platforms could be added later of course. I've 
> also included a test that covers most of the scenarios.
> http://cr.openjdk.java.net/~alanb/8199433/webrev/
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180319/44bcb7e2/attachment.html>


More information about the nio-dev mailing list