On Thu, 3 May 2007, Alfred Perlstein wrote:
* Randall Stewart <[EMAIL PROTECTED]> [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?
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!
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
