Jason Thorpe <thorpej@nas.nasa.gov> writes:

> On Tue, 13 Jan 1998 04:13:20 -0800 (PST) 
>  Nathan Gelbard <gelbardn@3jane.hurrah.com> wrote:
> 
>  > > The patch (against 1.2E sources) I got then which worked for me was
>  > 
>  > > *** linux_socket.c.orig       Thu Jul  3 20:02:19 1997
>  > > --- linux_socket.c    Thu 
>  > 
>  > I applied the patch, and everything is working GREAT NOW! Thanx much.
>  > This should be changed in the kernel tree.
> 
> But is this really correct in all cases?  Should this be done maybe
> only on non-blocking sockets?  OR, does Linux always have these semantics?

As the author of the patch, I want to state for the record that I
don't know what I'm doing, that it was a quick hack based on an
improbable theory, and that it should *not* be committed to the tree
without further research.

I now have access to a linux box, which I didn't at the time, so I may
be able to test these theories myself.

In particular, it may be that Linux doesn't show this odd behavior on
connects, and that I am patching the symptom instead of the cause of
another bug. In this case, a plausible candidate would be select, on
which the Linux JDK relies heavily and which does appear in ktraces to
return inexplicably sometimes. If the select against a connecting
socket returned early (say, due to an alarm signal, which also occur
everywhere in the ktraces for thread scheduling I suspect), and the JDK
thought that meant the connect had completed or failed, that would
also explain its behavior and the subsequent error. On the other hand,
I am pretty hazy on the details at this point since I played with this
more than a year ago.

I know there is a long history of problems and unofficial patches to
the linux select() emulation in netbsd, but I don't know the
details. If anyone does, please fill me in.

nd