harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [classlib][nio] epoll()-based Selector
Date Mon, 08 Oct 2007 09:46:26 GMT
Hi, Paulex,

> Amazing work, Aleksey!
Thanks, I was waiting for it :)

> Seems RI[1] is adapative here, i.e., use epoll when 2.6 kernel is detected,
> is it possible for Harmony to implement in similar way? Of course this can
> be further work and doesn't necessary to prevent this patch to be applied.
I believe it could be done in launcher which could detect the kernel
where Harmony starts and then instantiate right SelectorProvider. I
don't know the details for Harmony launcher though, it's just the
guess. This is in some way contrary with portlib implementation - we
could even implement optimized versions for Selector for Windows and
Linux separately.

> Though have a quick look, I had a trivial issue in the patch, seems
> EpollSelectionKeyImpl is just same with SelectionKeyImpl, in concept it's
> reasonable because epoll() is just a different system call, and can be
> transparent to Java API, so is it possible to just use SelectionKeyImpl in
> EpollSelectorImpl?
That was done for compatibility across different Selector
implementations. Current version of legacy SelectionKeyImpl lack some
functionality: for example, EpollSelectionKeyImpl stores internal
index in the its fields and also have the callbacks to the Selector
for handling  key modification events. Legacy selector does not
provide the targets for that callbacks (see modKey()), so I had to
fork the SelectionKeyImpl and stick it to EpollSelectorImpl
explicitly. However, if we will have [1] committed to the trunk, we
could merge the implementations together, though I bet to leave the
separate implementations.

[1] https://issues.apache.org/jira/browse/HARMONY-4869

View raw message