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