From owner-freebsd-arch@FreeBSD.ORG  Wed Aug 20 16:00:40 2014
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 2693371A;
 Wed, 20 Aug 2014 16:00:40 +0000 (UTC)
Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1])
 (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id F0661307E;
 Wed, 20 Aug 2014 16:00:39 +0000 (UTC)
Received: from jhbbsd.localnet (unknown [209.249.190.124])
 by bigwig.baldwin.cx (Postfix) with ESMTPSA id D78A1B9C4;
 Wed, 20 Aug 2014 12:00:38 -0400 (EDT)
From: John Baldwin <jhb@freebsd.org>
To: Benjamin Kaduk <bjk@freebsd.org>
Subject: Re: current fd allocation idiom
Date: Wed, 20 Aug 2014 11:10:10 -0400
User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; )
References: <20140717235538.GA15714@dft-labs.eu>
 <20140813015627.GC17869@dft-labs.eu>
 <alpine.GSO.1.10.1408151916150.21571@multics.mit.edu>
In-Reply-To: <alpine.GSO.1.10.1408151916150.21571@multics.mit.edu>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201408201110.10431.jhb@freebsd.org>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
 (bigwig.baldwin.cx); Wed, 20 Aug 2014 12:00:38 -0400 (EDT)
Cc: Konstantin Belousov <kostikbel@gmail.com>,
 Mateusz Guzik <mjguzik@gmail.com>, freebsd-arch@freebsd.org
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 16:00:40 -0000

On Friday, August 15, 2014 7:20:03 pm Benjamin Kaduk wrote:
> On Tue, 12 Aug 2014, Mateusz Guzik wrote:
> 
> > On Tue, Aug 12, 2014 at 09:31:15PM -0400, Benjamin Kaduk wrote:
> > > On Tue, Aug 12, 2014 at 7:36 PM, Mateusz Guzik <mjguzik@gmail.com> 
wrote:
> > >
> > > > I would expect soabort to result in a timeout/reset as opposed to 
regular
> > > > connection close.
> > > >
> > > > Comments around soabort suggest it should not be used as a replacement
> > > > for close, but maybe this is largely because of what the other end 
will
> > > > see. That will need to be investigated.
> > > >
> > > >
> > > I added some text regarding soabort to socket.9 in r266962 -- does that
> > > help clarify the situation?
> > >
> >
> > Nope. :-)
> >
> > It is unclear if the only motivation here is making sure nobody else
> > sees the socket when given thread calls soabort. This would be easily
> > guaranteed in here: fd allocation failed, fp with given socket was never
> > exposed to anyone.
> >
> > So, if you say soabort would work here just fine, I'm happy to use it
> > and blame you for problems. :-)
> 
> Hmm, I was hoping that jhb would chime in and save me from being on the
> hook, but it does look like soabort() would be acceptable in this case.

I think having the EMFILE/ENFILE case use the same exact logic as a listen 
queue overflow (i.e. soabort()) is correct.

-- 
John Baldwin