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

["Boehm, Hans" <hans dot boehm at hp dot com>]

On Linux, I believe the handlers should be getting installed with
SA_RESTART.  See GC_stop_init().

SUSV3 states that it is implementation defined whether select pays
attention to SA_RESTART.  I think it is silent about poll.

There may not be any way to avoid this behavior unless the kernel gives
us another thread stopping mechanism.  But it seems to me that just
redoing the poll after an EINTR (possibly after some checking to
preclude other signals demanding different treatment) should be fine.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] 
> On Behalf Of David Daney
> Sent: Tuesday, September 19, 2006 8:40 AM
> To: Marco Trudel
> Cc: GCJ
> Subject: Re: poll(...) gets "Interrupted system call" on jni
> 
> 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
> 
>