From owner-freebsd-arch@FreeBSD.ORG Fri Apr 9 23:09:46 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 362CD1065673; Fri, 9 Apr 2010 23:09:46 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id F035C8FC0A; Fri, 9 Apr 2010 23:09:45 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id B2BF3358C2C; Sat, 10 Apr 2010 01:09:44 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 9E73A17533; Sat, 10 Apr 2010 01:09:44 +0200 (CEST) Date: Sat, 10 Apr 2010 01:09:44 +0200 From: Jilles Tjoelker To: Robert Watson Message-ID: <20100409230944.GB7317@stack.nl> References: <20100404175140.GB40499@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arch@freebsd.org Subject: Re: so_rcv_sx, deadlkres, SIGSTOP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 23:09:46 -0000 On Mon, Apr 05, 2010 at 11:13:31PM +0100, Robert Watson wrote: > On Sun, 4 Apr 2010, Jilles Tjoelker wrote: > > The SX locks so_snd_sx and so_rcv_sx can be legitimately held for arbitrary > > amounts of time, while waiting until a send or recv is possible. Any other > > threads wanting to send/recv on the socket will sleep interruptibly on the > > corresponding SX. If deadlkres is activated, it may detect a deadlock even > > though there is no problem. > Actually, on the whole, socket buffer sx lock acquisition is interruptible. > There are a few exceptions, such as during socket shutdown, and in an RPC > layer or two, but in the general case we want Ctrl-C to interrupt recv() and > send(), so use interruptible sleeps. The exceptions are: * portalfs uses SB_NOINTR to make both sblock() and sbwait() uninterruptible, for connections to a daemon on the local machine * sorflush() (part of shutdown) uses SBL_NOINTR to wait for socket buffer activity to terminate after calling socantrcvmore(); this seems OK because it will not wait for the network, and must be because shutdown(2) should not return EINTR * kern_sendfile() uses SBL_NOINTR with sblock() but then sbwait()s interruptibly; this doesn't make sense to me because sblock() waits for the network just like sbwait() except that another thread happens to be waiting already -- Jilles Tjoelker