From owner-freebsd-net@FreeBSD.ORG  Fri Mar 29 21:31:21 2013
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
 by hub.freebsd.org (Postfix) with ESMTP id B39FBBF3;
 Fri, 29 Mar 2013 21:31:21 +0000 (UTC)
 (envelope-from carl.shapiro@gmail.com)
Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52])
 by mx1.freebsd.org (Postfix) with ESMTP id EC3E7BD7;
 Fri, 29 Mar 2013 21:31:20 +0000 (UTC)
Received: by mail-ee0-f52.google.com with SMTP id d17so365544eek.39
 for <multiple recipients>; Fri, 29 Mar 2013 14:31:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=x-received:mime-version:in-reply-to:references:from:date:message-id
 :subject:to:cc:content-type;
 bh=UNRVeLlZ3+LV1qGwRyfHk/1RtGcJ+c2dGt68gzMzVqU=;
 b=Xs84vx7JVZwaigHnDXo1VAOnsgbv2RPy9I/Pt2Vg6Tt5nEOCwmARa+OcMoCYmT70og
 8wopwBt64V9hCYfF9qeHQWDOjyHfXh0gY7JDFffO6wUcONcrZdV/s6ZbukOj3oTYUM65
 O4p5hr1SbtVEy9xHMAdNZeECXlnlDUXXbZS4y2tcT49eGppmznK5EphrMnUJTUCU8dn0
 pgcMroRBKRw91EIMh64aGa4e4E9t3rOsa+ZOX19GX7Gp3a9FmLhCVKdDuYahmerkmve6
 jAtatIus0FxBYX9PQsYuRUfo6S9HwMnU64wRHDZBz26pZvPJtVH9jjVE9tTbgYWg4uel
 7Ifw==
X-Received: by 10.14.207.200 with SMTP id n48mr11887242eeo.4.1364592679631;
 Fri, 29 Mar 2013 14:31:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.14.129.2 with HTTP; Fri, 29 Mar 2013 14:30:59 -0700 (PDT)
In-Reply-To: <515475C7.6010404@FreeBSD.org>
References: <515475C7.6010404@FreeBSD.org>
From: Carl Shapiro <carl.shapiro@gmail.com>
Date: Fri, 29 Mar 2013 14:30:59 -0700
Message-ID: <CANVK_QgnC-pLGwh7Oad87JO_z1WmLeY3kfT9HhdpSzMnpjdNgA@mail.gmail.com>
Subject: Re: close(2) while accept(2) is blocked
To: Andriy Gapon <avg@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.14
Cc: freebsd-net@freebsd.org, FreeBSD Hackers <freebsd-hackers@freebsd.org>
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2013 21:31:21 -0000

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.