close(2) while accept(2) is blocked

[Carl Shapiro]

On Thu, Mar 28, 2013 at 9:54 AM, Andriy Gapon <avg at freebsd.org> wrote:

> But the summary seems to be is that currently it is not possible to break
> a thread
> out of accept(2) (at least without resorting to signals).
>

This is a known problem for Java.  Closing a socket that another thread is
block on is supposed to unblock a thread and throw a SocketException.

http://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#close()

In other operating systems, such as Solaris and MacOS X, closing the
descriptor causes blocked system calls to return with an error.

FreeBSD (and Linux) do not behave this way.  There, a JVM must do extra
bookkeeping to associate file descriptors with threads blocked on the
descriptor.  This allows the close method to identify blocked threads and
send them a signal.  On those threads the caller of the blocking method
must further distinguish an error return as being caused by a signal sent
on behalf of close.

It is not obvious whether there is any benefit to having the current
blocking behaviour.  Threads are an afterthought in UNIX so this could just
be an oversight.  It would make a high-level language runtimes simpler if
FreeBSD behaved more like Solaris and MacOS X.