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
