poll(...) gets "Interrupted system call" on jni
Tue Sep 19 15:01:00 GMT 2006
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
> 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.
The fact that Sun's runtime does not cause EINTR to be returned is a
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.
More information about the Java