Problems persist in KQueueSelectorProvider (Mac) in 7u6 ea

[Jason Greene]

On Aug 20, 2012, at 2:19 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 17/08/2012 22:43, Jason T. Greene wrote:
>> 
>> Sleep and yield don't seem to prevent the dup2 issue, so there must be something more complex going on. For whatever reason I have yet to trigger it with the setInterest patch
>> 
>> Here is the kernel stack:
> Thanks for checking, it does appear that something else is going on. It would be really useful if you could create a standalone test case that duplicates it (don't know if that is possible as I assume you are seeing this in conjunction with lots of middleware).

Unfortunately all my efforts to reproduce it in a simple test failed. I even attempted a very aggressive native kqueue stress test, but it worked as expected.Looking at the kernel source, this could only happen if the pending I/O refcount is off, or there is a lost signal. A blocking operation or pending select will keep the count up, but those are suppose to be interrupted. The really odd thing is that the process will always become a zombie, and when killed all pending ops should have been cancelled. 

At this point the only way I can think of to debug this further is to add custom kernel debugging to track the io counts. I probably won't have time for that unless we still see the issue again from some other scenario.

> 
>> 
>> Ok I have tested this very thoroughly, and I think it's ready for submission. This includes jdk 6 (snow leopard, lion, mountain lion) and 7 (lion, mountain lion). I also ran through the nio selector tests, all pass.
>> 
>> What process should I follow?
> Thanks for testing in all environments (I'm surprised that it works with 6 as we have made several changes to this code since the the original Apple contribution).

I backported the patched JDK 7 impl to test 6. It only requires a few changes (makePipe change, and methods moving from FileDispatcher into FDImpl). 

> For process then you need a sponsor to commit it for you so I will do that for you, hopefully this week, I just need to spend a bit of time to look at it more closely.

Great thanks!



> 
>> 
>> A potential change that could be made, that I think should be left for the future should perf testing ever show it's importance, is that the kqueue change list could be combined into one syscall, instead of a list of N syscalls.
>> 
> Yes, I think that would be a good improvement but it does not need to be in this patch. We do in /dev/poll Selector so you might get some ideas there.
> 
> So thanks for the bug report and patch, I will get back to you soon.


Ok thanks