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

[David Daney <ddaney at avtrex dot com>]

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