poll(...) gets "Interrupted system call" on jni

David Daney ddaney@avtrex.com
Tue Sep 19 15:39:00 GMT 2006


Marco Trudel wrote:
> David Daney wrote:
>> Marco Trudel wrote:
>>> Hello all
>>>
>>> For a little variety in my life, I run into a problem with GCJ on 
>>> linux. I use a --disable-shared GCJ, built yesterday evening 
>>> (revision 117030)...
>>>
>>> I have a java application that calls a native lib over JNI. This lib 
>>> performs a poll() on a network socket in a loop. This all works 
>>> flawless when running with a sun jdk. As soon as I compile the 
>>> application with GCJ, the poll() sometimes fail and sets errno to 4 
>>> (Interrupted system call).
>>>
>>> Google told me that this can (respectively should) be ignored and 
>>> indeed, everything works if I just continue in the loop. But I'm a 
>>> little confused why this only happens when the application is 
>>> compiled with GCJ.
>>> What makes me think that GCJ might do something bad is, that the lib 
>>> is a widely used java library. So I guess no one run into this bug 
>>> with a "normal" JRE so far...
>>>
>>> I'm not entirely sure if it's a GCJ problem. Actually I don't even 
>>> know what "Interrupted system call" means exactly (I guess the poll 
>>> was simply interupted). Any commends welcome...
>>
>> This is probably the result of of libgcj's Garbage Collector (GC) 
>> operating normally.  The GC sends signals to each thread which causes 
>> them all to enter a stop-the-world state.  When the GC is finished, 
>> all the threads are resumed.  When the threads are resumed, any that 
>> were blocked in a blocking system call (like poll()) will return with 
>> EINTR.  Normally you would just retry the system call.
>
> Ah, yes. That sounds very reasonable. Thank you!
> By "retry the system call", do you mean to do it myself (I do, it 
> works) or that this could be done automatically?

If poll() is returning EINTR, you have to manually re-execute the system 
call (as you say you are doing).
>
>
>> The fact that Sun's runtime does not cause EINTR to be returned is a 
>> different matter...
>
> Well, doesn't matter...
>
>
>> I don't know if the GC's signal handlers are installed with 
>> SA_RESTART, or if that would solve the problem.  It might be worth 
>> looking into.  You could look at the GC sources where the signal 
>> handlers are installed, and if they don't use SA_RESTART add it and 
>> see what happens.
>
> Well, I assume if they aren't installed with SA_RESTART, this probably 
> has a reason and I'm afraid of side-effects.

Many times there is not a reason.  Have no fear.  Forge ahead.  Fear of 
breaking things is an impediment to progress... 

> Would this automatically retry the poll without any needed interaction 
> from me respectively my code?
>
I think it would restart the call automatically, but I am not positive.

I am just reading e-mail and not looking at the GC sources, so I really 
have no idea about which options are used with the GC's signal 
handlers.  It is really just idle speculation about what might happen...

David Daney



More information about the Java mailing list