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

[Alfred Perlstein]

* Randall Stewart <rrs at 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