From owner-freebsd-arch@FreeBSD.ORG Sun Apr 4 20:40:58 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 6C5141065678 for ; Sun, 4 Apr 2010 20:40:58 +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 33E828FC45 for ; Sun, 4 Apr 2010 20:40:58 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 9E88735A844; Sun, 4 Apr 2010 22:40:57 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 8A0B717531; Sun, 4 Apr 2010 22:40:57 +0200 (CEST) Date: Sun, 4 Apr 2010 22:40:57 +0200 From: Jilles Tjoelker To: Kostik Belousov Message-ID: <20100404204057.GA43042@stack.nl> References: <20100404175140.GB40499@stack.nl> <20100404181233.GH2415@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100404181233.GH2415@deviant.kiev.zoral.com.ua> 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: Sun, 04 Apr 2010 20:40:58 -0000 On Sun, Apr 04, 2010 at 09:12:33PM +0300, Kostik Belousov wrote: > On Sun, Apr 04, 2010 at 07:51:40PM +0200, 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. > > If a SIGSTOP or similar comes in while waiting until send/recv is > > possible, the SX is held across the suspension and noone will be able to > > send/recv on the socket until the process is resumed. On the other hand > > a thread waiting for the SX can be suspended without harm. Adding PBDRY > > to various sleeps may help but may also introduce other problems > > (SIGSTOP disturbing the functioning of the process more, possibly with > > stuff like SO_RCVTIMEO). > Could you, please, elaborate on this (interaction between PBDRY and some > socket timeout stuff) ? A SIGSTOP will currently not affect a SO_RCVTIMEO timeout, just like it does not affect a nanosleep(2). Demonstration is analogous to my earlier example with /bin/sleep, where ./socktimeout is the program below: % /usr/bin/time ./socktimeout ^Z % fg # such that the program can run again 10 seconds after starting socktimeout: read: Resource temporarily unavailable 10.00 real 0.00 user 0.00 sys % PBDRY would cause an immediate Interrupted system call return. I don't know how much SO_RCVTIMEO/SO_SNDTIMEO are used (a POSIX application cannot rely on their support for any kind of socket), and it is likely applications using it can already get EINTR from signal handlers. #include #include #include #include #include #include int main(int argc, char *argv[]) { int sock; sock = socket(AF_LOCAL, SOCK_DGRAM, 0); if (sock == -1) err(1, "socket"); if (setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, &(const struct timeval){ 10, 0 }, sizeof(struct timeval)) == -1) err(1, "setsockopt(SO_RCVTIMEO)"); errno = 0; if (read(sock, (char[]){ 0 }, 1) != 1) err(1, "read"); return 0; } -- Jilles Tjoelker