From owner-cvs-src@FreeBSD.ORG Thu May 3 17:30:08 2007 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 202E816A404; Thu, 3 May 2007 17:30:08 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0A40013C447; Thu, 3 May 2007 17:30:08 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 480261A4D93; Thu, 3 May 2007 10:30:43 -0700 (PDT) Date: Thu, 3 May 2007 10:30:43 -0700 From: Alfred Perlstein To: Robert Watson Message-ID: <20070503173043.GM67243@elvis.mu.org> References: <200705031442.l43Egggi064069@repoman.freebsd.org> <463A0198.3040507@cisco.com> <20070503160413.GL67243@elvis.mu.org> <20070503180707.D30997@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070503180707.D30997@fledge.watson.org> User-Agent: Mutt/1.4.2.2i 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-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2007 17:30:08 -0000 * 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. I'm somewhat surprised that an attempt to move from sleep to cv based rendevous wasn't attempted first. -- - Alfred Perlstein