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

[Robert Watson]

On Thu, 3 May 2007, Alfred Perlstein wrote:

> * Robert Watson <rwatson at FreeBSD.org> [070503 10:08] wrote:
>
>>> 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!
>
> OK, please do your usual awesome benchmarking though so that this potential 
> fix doesn't wind up being a performance pessimizing stopgap.

Certainly.  Attilio is working on producing patches to add signal-aware 
versions of the two sleeping locking primitives (sx_xlock and sx_slock) used 
here.  Assuming this goes into CVS in the next day or so, I'll fix up the 
changes as-is; otherwise, I'll back them out until the necessary sx(9) 
extensions are in place.

> I'm somewhat surprised that an attempt to move from sleep to cv based 
> rendevous wasn't attempted first.

The goal of the exercise was to move from a custom locking primitive to a 
standard locking primitive.  Replacing a hacked together lock constructed with 
signal and msleep with a hacked together lock constructed with condition 
variables and mutexes wouldn't improve the world a whole lot.  Unfortunately, 
I overlooked the signal interruption bit of it, which requires minor 
extensions to sx(9) in order to address.  Hopefully that will be done shortly.

Robert N M Watson
Computer Laboratory
University of Cambridge