On Sun, 16 Sep 2001, Jason R Thorpe wrote:

> On Sun, Sep 16, 2001 at 11:32:55AM -0700, Matthew Jacob wrote:
>
>  > There was this SCSIPI_CHAN_CALLBACK defined- but it seems to me that because
>  > this is a public i/f and can only be busy with one callback at a time, that it
>  > was worth devoting an extra bit to having scsipi_periph_timed_thaw have the
>  > completion thread do the queue running.
>  >
>  > Here are the diffs- seems to work (ignore the 'printf' in the completion
>  > thread- this is WIP).
>
> Looks good to me -- once you feel like it is ready, please commit it.
>

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.

-matt