Re: Retry ServerSocket.accept (java-net.c _accept) on EINTR

[Mark Wielaard]

Hi,

On Sun, 2004-04-25 at 20:34, Archie Cobbs wrote:
> Hmm.. I wonder how many other instances of this bug there are.
> 
> E.g., connect(2), read(2), write(2), open(2), close(2), etc... can
> all return EINTR if interrupted by a signal (often depends on the
> situation of course).
> 
> For system calls that don't normally block (like read(2) from a
> normal file), this would be very unlikely but in theory there's
> nothing preventing a well-timed signal from causing EINR, though
> in practice it probably depends on the O/S whether this can actually
> happen.
> 
> If some O/S does allow this, then we possibly have lots of very
> rare race condition bugs of this form...

Unfortunately we probably have some more of these bugs. But we do check
this now for java-net receive() and accept() and the FileChannelImpl
methods in java-nio for read() and write(). We really need an audit for
this issue throughout all of the JNI/C code. Maybe the target-native
layer can help here by always restarting a system call automatically
when errno is EINTR? On the other hand, the target-native layer seems to
obscure these kind of issues and it might be an idea to do things more
directly by just autoconfiscating[1] the complete JNI source and getting
rid of the target-native layer.

I good source of inspiration is the CNI implementation of the runtime
specific code in libgcj. They seem to have designed their system calls
from the start with this in mind.

Cheers,

Mark

[1] http://sources.redhat.com/autobook/autobook/autobook_237.html

signature.asc
Description: This is a digitally signed message part