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

[Marco Trudel <mtrudel at gmx dot ch>]

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?


> 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. Would this automatically 
retry the poll without any needed interaction from me respectively my code?


thanks
Marco