Date: Thu, 3 May 2007 21:30:15 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: cvs-src@FreeBSD.org, Randall Stewart <rrs@cisco.com>, 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 Message-ID: <20070503212712.C32808@fledge.watson.org> In-Reply-To: <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> <20070503173043.GM67243@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 May 2007, Alfred Perlstein wrote: > * Robert Watson <rwatson@FreeBSD.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070503212712.C32808>