From owner-cvs-all@FreeBSD.ORG Thu May 3 20:30:17 2007 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C9F616A404; Thu, 3 May 2007 20:30:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9E1F513C46E; Thu, 3 May 2007 20:30:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5678346B80; Thu, 3 May 2007 16:30:15 -0400 (EDT) Date: Thu, 3 May 2007 21:30:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alfred Perlstein In-Reply-To: <20070503173043.GM67243@elvis.mu.org> Message-ID: <20070503212712.C32808@fledge.watson.org> References: <200705031442.l43Egggi064069@repoman.freebsd.org> <463A0198.3040507@cisco.com> <20070503160413.GL67243@elvis.mu.org> <20070503180707.D30997@fledge.watson.org> <20070503173043.GM67243@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, Randall Stewart , src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_debug.c uipc_sockbuf.c uipc_socket.c uipc_syscalls.c src/sys/netinet sctputil.c src/sys/sys socketvar.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2007 20:30:17 -0000 On Thu, 3 May 2007, Alfred Perlstein wrote: > * Robert Watson [070503 10:08] wrote: > >>> Now process B is in an uninterruptable wait until the remote side drains >>> the pipe. >>> >>> The same problem might happen (even easier to reproduce) when there are >>> multiple readers. >>> >>> Of course this all depends on me missing something. >>> >>> Can you explain? >> >> You are entirely right -- I'm not sure how I missed the SB_NOINTR flag >> semantics in sb_lock(), but apparently I did. I'm talking to Attilio right >> now about adding an interruptible version of the sleeping exclusive lock >> acquire and will follow up on this shortly. Thanks for pointing this out! > > OK, please do your usual awesome benchmarking though so that this potential > fix doesn't wind up being a performance pessimizing stopgap. Certainly. Attilio is working on producing patches to add signal-aware versions of the two sleeping locking primitives (sx_xlock and sx_slock) used here. Assuming this goes into CVS in the next day or so, I'll fix up the changes as-is; otherwise, I'll back them out until the necessary sx(9) extensions are in place. > I'm somewhat surprised that an attempt to move from sleep to cv based > rendevous wasn't attempted first. The goal of the exercise was to move from a custom locking primitive to a standard locking primitive. Replacing a hacked together lock constructed with signal and msleep with a hacked together lock constructed with condition variables and mutexes wouldn't improve the world a whole lot. Unfortunately, I overlooked the signal interruption bit of it, which requires minor extensions to sx(9) in order to address. Hopefully that will be done shortly. Robert N M Watson Computer Laboratory University of Cambridge