Re: workqueue_drain

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Wed, 20 Dec 2017 22:48:10 +0100
> From: Michael van Elst <mlelstv%serpens.de@localhost>
> 
> On Thu, Dec 21, 2017 at 05:32:58AM +0800, Paul Goyette wrote:
> 
> > again (no work can be enqueued if already in the queue).  But I don't
> > see how "remember the last work enqueued and wait for it to be done
> > before destroying" is more versatile than "waiting for all to be done
> > before destroying".  It certainly seems that the latter is a simpler
> > approach.
> 
> The function is more versatile as it allows other uses than preparing
> the queue destruction.
> 
> It would be much easier, if the work item had a state field....

I drafted a few ideas along these lines a while ago, including
unifying the API for thread context and softint context into just
different priority levels, and pooling threads so that idle workqueues
don't cost idle kthreads:

https://www.NetBSD.org/~riastradh/tmp/20140517/
https://www.NetBSD.org/~riastradh/tmp/20140726/kern_task_up.c
https://mail-index.NetBSD.org/tech-kern/2014/07/23/msg017394.html

Maybe the ideas were too disjointed or overengineered; it never went
anywhere.  rmind@ proposed adding workqueue_drain to workqueue(9) and
maybe something else as a much simpler variation, but I don't remember
where his patch went.