> Date: Wed, 20 Dec 2017 22:48:10 +0100 > From: Michael van Elst <mlel...@serpens.de> > > 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.