From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 23:25:16 2014 Return-Path: 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 CDFE87E0; Fri, 15 Aug 2014 23:25:16 +0000 (UTC) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 549B92A9C; Fri, 15 Aug 2014 23:25:15 +0000 (UTC) X-AuditID: 1209190e-f79946d000007db1-e1-53ee95a6ef85 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id F7.5F.32177.6A59EE35; Fri, 15 Aug 2014 19:20:06 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s7FNK6pu029459; Fri, 15 Aug 2014 19:20:06 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7FNK4Pm020246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Aug 2014 19:20:05 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7FNK3Zf028276; Fri, 15 Aug 2014 19:20:03 -0400 (EDT) Date: Fri, 15 Aug 2014 19:20:03 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Mateusz Guzik Subject: Re: current fd allocation idiom In-Reply-To: <20140813015627.GC17869@dft-labs.eu> Message-ID: References: <20140717235538.GA15714@dft-labs.eu> <20140718155959.GN93733@kib.kiev.ua> <20140718191928.GB7179@dft-labs.eu> <201408111124.52064.jhb@freebsd.org> <20140812233617.GA17869@dft-labs.eu> <20140813015627.GC17869@dft-labs.eu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYrdT0V0+9V2wwR0+i9nTpzFZ7D1yndmi YdpjNovGg4tZHFg8Znyaz+Kxc9Zd9gCmKC6blNSczLLUIn27BK6MmW9CCiZzVsz9+I2tgbGd vYuRg0NCwERi2QqWLkZOIFNM4sK99WxdjFwcQgKzmSSu9m9gh3A2MkosXvmDBcI5xCSxrG8p M4TTwCix7eJPJpB+FgFtidNnpoDZbAJqEo/3NrNCzFWU2HxqEjOILSKgKvH86HqwOLNAgcSu Xe/B4sICGhJ3dq4Cu4NTwFDi0JXzYHFeAUeJ0+/3gMWFBNYzSWz44g9iiwroSKzeP4UFokZQ 4uTMJywQM7Uklk/fxjKBUWgWktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI31cjNL 9FJTSjcxgkKaU5JvB+PXg0qHGAU4GJV4eAXE3wULsSaWFVfmHmKU5GBSEuUNbgcK8SXlp1Rm JBZnxBeV5qQWH2KU4GBWEuFd5QaU401JrKxKLcqHSUlzsCiJ8761tgoWEkhPLEnNTk0tSC2C ycpwcChJ8M6dAtQoWJSanlqRlplTgpBm4uAEGc4DNPwOSA1vcUFibnFmOkT+FKOilDjvU5CE AEgiozQPrheWcl4xigO9Isx7FKSKB5iu4LpfAQ1mAhpcs/ktyOCSRISUVAPjkv6kJ3f/d7Ab MvIvXcRo5qu73qHW8TS/d0vZqcbsGsF98gwazjvc3n7Uuryo44Xe2qs32Z6cEZ//aPex/Z9Y q13VGFLOrM6I3XW1S7jowGZ+7Tf6C2Q+Pt7T9OSAs+/J8OuCX7fkKzzVXDDh8SM/r4Ky06U3 niYIVER22E9Vv2LtyzzjRMBhJZbijERDLeai4kQAYpBHOxQDAAA= Cc: Konstantin Belousov , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 23:25:17 -0000 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 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. -Ben