From owner-freebsd-arch@FreeBSD.ORG Wed Aug 13 01:56:33 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 4F9FA3C0; Wed, 13 Aug 2014 01:56:33 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B58EA265C; Wed, 13 Aug 2014 01:56:32 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id ho1so6702344wib.14 for ; Tue, 12 Aug 2014 18:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=2SVmS/SN5+eeOjPquTCv4jEaX1wk+hGI/7Hja8hjaxs=; b=wEmBEaVWTwj5P61E25BPzJRB66Lq8kMQlFhba5Dex1vVeD/HQuIdBmlSt9sDs/W0Tc +PNU38Plt+8iIBazq1vnpDF6Xl2HAhR/36Stie3ae9QkXlbODvshq/M1cbzJLWGGuyAw CAaBY/xJBFIsQZGUPIA84uUC2Ue62y4kfEOcvWifRzq44n6CDllCX7q4G8eYhK7jfXdJ 6Cu+Z6OUSi/tuFPK3LMQmpwKeMl5D3Ojbf/fS10SaMLSITMZV2CsFBFMJzKYtzdcSdpF jMSk/f/YzkCMVP9+7T2MUPXkpJTvP9nJ7WJbix89sO2R7n2vIs59tsMeGKxX37n1McPG 2qvA== X-Received: by 10.180.94.34 with SMTP id cz2mr35788486wib.74.1407894990973; Tue, 12 Aug 2014 18:56:30 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id j5sm993076wjf.35.2014.08.12.18.56.29 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 12 Aug 2014 18:56:30 -0700 (PDT) Date: Wed, 13 Aug 2014 03:56:27 +0200 From: Mateusz Guzik To: Benjamin Kaduk Subject: Re: current fd allocation idiom Message-ID: <20140813015627.GC17869@dft-labs.eu> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 13 Aug 2014 01:56:33 -0000 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. :-) -- Mateusz Guzik