Date: Thu, 3 May 2007 09:04:13 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Randall Stewart <rrs@cisco.com> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Robert Watson <rwatson@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: <20070503160413.GL67243@elvis.mu.org> In-Reply-To: <463A0198.3040507@cisco.com> References: <200705031442.l43Egggi064069@repoman.freebsd.org> <463A0198.3040507@cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Randall Stewart <rrs@cisco.com> [070503 08:35] wrote: > Robert Watson wrote: > >rwatson 2007-05-03 14:42:42 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/kern uipc_debug.c uipc_sockbuf.c uipc_socket.c > > uipc_syscalls.c > > sys/netinet sctputil.c > > sys/sys socketvar.h > > Log: > > sblock() implements a sleep lock by interlocking SB_WANT and SB_LOCK > > flags > > on each socket buffer with the socket buffer's mutex. This sleep lock is > > used to serialize I/O on sockets in order to prevent I/O interlacing. I'm looking at the diff... it looks like you dropped signal handling from sblock? Is that true and if so was that intentional? I'm worried that the following situation can happen: process A: init large write to socket. process A: gets sblock process A: fills socketbuffer process A: waits for space. process B: tries to write to socket 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? -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070503160413.GL67243>