cv_timedwait() & exiting procs

[Julian Elischer]

easiest answer..
Rip out the EWOULD BLOCK clause.. it should NOT be there..
(teh one in John's email)
I'm about to check in that change anyhow..


On Mon, 31 Mar 2003, Andrew Gallatin wrote:

> 
> 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
> 
> 
>