poll(...) gets "Interrupted system call" on jni
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...
More information about the Java