bsd-xfs, signaling to break a wait

[Robert Watson]

Arla Folk,

I've been playing with XFS some over the last week or so.  I ran into the
following behavior:

When a user process touches a section of the mounted xfs file system and
the appropriate data is not in the kernel cache or owned by the kernel,
then the user process is blocked while a request message is sent to the
daemon listening on /dev/xfsn, and remains blocked until an appropriate
wakeup message is sent with the sequence number of the request message.
If additional user processes want to access the same object that that
an existing outgoing request is for, they also block, but additional
messages are not sent (or at least, this is true of getroot).

The first process can be signaled to break its wait on the object. 
Example: \ls -d /cachefs (where /cachefs is the mountpoint).  Pressing
ctrl-c to interrupt the first user process works.  However, if you ctrl-c
a second process running the same command, but started after the first
process, it will not be released from the block until the first user
process is released.  That is, its blocking appears to be uninterruptable. 

Preferred behavior would seem to be: if any process blocking on a message
receives a signal (such as ctrl-c) it may be woken up, not just the first
one (presumably the first in the chain of sleepers?)  

  Robert N Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
Safeport Network Services             http://www.safeport.com/