On Fri, Dec 22, 2017 at 4:12 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Thu, Dec 21, 2017 at 5:56 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: >> On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst <mlel...@serpens.de> wrote: >>> ozak...@netbsd.org (Ryota Ozaki) writes: >>> >>>>On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst <mlel...@serpens.de> >>>>wrote: >>>>> What about a method that waits for a specific work to complete? >>> >>>>It might be useful but how it works in this case? >>> >>> You could remember the last work enqueued and wait for it to finish >>> before destroying the queue. For this the wait function must handle >>> the case where the work already has finished. >>> >>> I would consider such a function more versatile than just a drain function. >> >> Oh I got it. Well, that should work for my cases (bridge, pppoe) because >> there is just one work. I'm not sure the API suits for other use cases. >> >> Anyway I'm trying to implement the API (workqueue_wait?). > > Here it is: http://www.netbsd.org/~ozaki-r/workqueue_wait.diff > > I think that workqueue_drain based on workqueue_wait would be that > workqueue_drain prepares a local work, enqueues it to the workqueue > and waits on it by workqueue_wait. (A workqueue with WQ_PERCPU needs > to repeat them on every CPUs.) IMHO if I want workqueue_drain, I > would implement it without workqueue_wait; that would be simpler.
I wrote a test for workqueue_wait: http://www.netbsd.org/~ozaki-r/workqueue_wait.test.diff I don't have strong persistence to workqueue_drain and workqueue_wait is OK to me. I'm going to commit workqueue_wait patches if no objections raised. Any others? Regards, ozaki-r