cv_timedwait() & exiting procs

[Andrew Gallatin]

Julian Elischer writes:
 > 
 > Some comments to your thoughts.. It would be a valid thought to allow
 > the syscall to complete if the sleep completed. but why? Also, Maybe the
 > test should also test if we are:
 > 
 > 1/ threading
 > and
 > 2/ not the thread that is actually DOING the exit()
 > (though exit doesn't do any sleeps that I KNOW of)

That would be nice, if I understand what you're saying.  

The scenario that I'm in is that I have character driver.  At certain
points, we send "commands" to the the device and sleep on a cv.  When
the device completes the command, it interrupts the host and the
interrupt handler does a cv_signal.  If the device does not respond
after some seconds, we consider the device dead.  One of these commands
is issued when the device is closed.

The problem occurs when an application does not call close himself,
rather he just exits, and our driver's close entry point is called
from the exit() code path.  The "command" associated with device
closes is issued in the context of this (single threaded) process.
All is well, and the device responds.  The interrupt happens.
cv_signal() is called.

But: cv_timedwait() then returns with EWOULDBLOCK.  Because
EWOULDBLOCK is returned, the driver assumes the timeout has been
exceeded and device has gone dead.

Sure, this is easy enough for me to fix in the driver code, but it
really makes FreeBSD's condvar interface look busted..

I was thinking that we could only return an error because of P_WEXIT
being set if P_WEXIT was not set when the cv call was entered.

Drew