From owner-freebsd-net@FreeBSD.ORG  Sat Mar 30 00:03:02 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 A2D05BA1;
 Sat, 30 Mar 2013 00:03:02 +0000 (UTC)
 (envelope-from bakul@bitblocks.com)
Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8])
 by mx1.freebsd.org (Postfix) with ESMTP id 8B57D11A;
 Sat, 30 Mar 2013 00:03:02 +0000 (UTC)
Received: from bitblocks.com (localhost [127.0.0.1])
 by mail.bitblocks.com (Postfix) with ESMTP id 32D7FB82A;
 Fri, 29 Mar 2013 16:54:31 -0700 (PDT)
To: Carl Shapiro <carl.shapiro@gmail.com>
Subject: Re: close(2) while accept(2) is blocked
In-reply-to: Your message of "Fri, 29 Mar 2013 14:30:59 PDT."
 <CANVK_QgnC-pLGwh7Oad87JO_z1WmLeY3kfT9HhdpSzMnpjdNgA@mail.gmail.com>
References: <515475C7.6010404@FreeBSD.org>
 <CANVK_QgnC-pLGwh7Oad87JO_z1WmLeY3kfT9HhdpSzMnpjdNgA@mail.gmail.com>
Comments: In-reply-to Carl Shapiro <carl.shapiro@gmail.com>
 message dated "Fri, 29 Mar 2013 14:30:59 -0700."
Date: Fri, 29 Mar 2013 16:54:31 -0700
From: Bakul Shah <bakul@bitblocks.com>
Message-Id: <20130329235431.32D7FB82A@mail.bitblocks.com>
Cc: freebsd-net@freebsd.org, Andriy Gapon <avg@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: Sat, 30 Mar 2013 00:03:02 -0000

On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro <carl.shapiro@gmail.com> wrote:
> 
> In other operating systems, such as Solaris and MacOS X, closing the
> descriptor causes blocked system calls to return with an error.

What happens if you select() on a socket and another thread
closes this socket?  Ideally select() should return (with
EINTR?) so that the blocking thread can some cleanup action.
And if you do that, the blocking accept() case is not really
different.

There is no point in *not* telling blocking threads that the
descriptor they're waiting on is one EBADF and nothing is
going to happen.

> It is not obvious whether there is any benefit to having the current
> blocking behaviour. 

This may need some new kernel code but IMHO this is worth fixing.