* 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 _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
