Date: Sat, 10 Apr 2010 01:09:44 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-arch@freebsd.org Subject: Re: so_rcv_sx, deadlkres, SIGSTOP Message-ID: <20100409230944.GB7317@stack.nl> In-Reply-To: <alpine.BSF.2.00.1004052309090.32745@fledge.watson.org> References: <20100404175140.GB40499@stack.nl> <alpine.BSF.2.00.1004052309090.32745@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100409230944.GB7317>