Date: Fri, 29 Mar 2013 14:30:59 -0700 From: Carl Shapiro <carl.shapiro@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-net@freebsd.org, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: close(2) while accept(2) is blocked Message-ID: <CANVK_QgnC-pLGwh7Oad87JO_z1WmLeY3kfT9HhdpSzMnpjdNgA@mail.gmail.com> In-Reply-To: <515475C7.6010404@FreeBSD.org> References: <515475C7.6010404@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 28, 2013 at 9:54 AM, Andriy Gapon <avg@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANVK_QgnC-pLGwh7Oad87JO_z1WmLeY3kfT9HhdpSzMnpjdNgA>