Subject: Re: change to scsipi_periph_timed_thaw
To: Matthew Jacob <mjacob@feral.com>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: tech-kern
Date: 09/17/2001 22:00:55
On Sun, Sep 16, 2001 at 01:25:37PM -0700, Matthew Jacob wrote:
> Umm- it extends a bit deeper. The problem is that the completion thread
> doesn't run until much later- so you can get stuck trying to wake up a thread
> that hasn't been started yet.
> 
> In this case we don't have XS_CTL_ASYNC set. The test for whether a BUSY
> condition should delay(9) or do the callout to tell the completion thread to
> unfreeze is just XS_CTL_POLL.
> 
> I'm a bit uncertain as to whether or not to go with inferring from the control
> flags whether this BUSY should be delay(9)'d or not- or whether it's also
> worth having a flag in the channel structure that says the completion thread
> is running or not (or I suppose I could use the proc pointer in the channel
> structure).
> 
> It might be less clunky to try and infer from the combo of
> 
> 	XS_CTL_ASYNC
> 	XS_CTL_POLL
> 	XS_CTL_NOSLEEP
> 
> what the right thing to do is. It also is true that it would be really
> useful to know whether or not your going to sleep to be waken up by
> a thread that will never get started :-).
> 
> Also, I've been looking a couple of DIAGNOSTIC points to check (like making
> sure that the freeze count doesn't go negative).
> 
> At any rate- opinions sought on this one. I'm inclined to just go with thread
> active or not- but I'm very open to alternate suggestions.

I'd go with this too. Looks like the cleaner way to solve it.

--
Manuel Bouyer <bouyer@antioche.eu.org>
--