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?
-Alfred
Well.. I can't.. I just did a small part of this..
I did not look at the code that Robert did on the
socket buffer side of things.. I only did the sblock() stuff
that Robert wanted in the sctputil.c
Now looking at the sx_lock code (for the first time).. I too
don't see how it is interrupted.. but I am sure Robert
thought of this.. I am chasing another SCTP bug right now
and have a huge integration project going on as well ... so
I don't have time to look at this..
Robert, what do you think of this scenario?
R
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
