On Wed, Dec 20, 2017 at 5:41 PM, Ryota Ozaki <ozak...@netbsd.org> wrote: > On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette <p...@whooppee.com> wrote: >> On Wed, 20 Dec 2017, Ryota Ozaki wrote: >> >>> Hi, >>> >>> workqueue_destroy requires that its queue doesn't have >>> any works (and no new work will be enqueued anymore) >>> before being called. Currently users of workqueue have >>> to ensure the contract by theirselves. It's possible >>> but it may need to add extra synchronization mechanisms >>> such as mutex and condvar only for that purpose. >>> >>> workqueue itself can provide an API to help the routine. >>> It, say workqueue_drain, waits for all pending works to >>> finish. With it the caller needs to only ensure that no >>> new work will be enqueued. >>> >>> Here is a patch: >>> http://www.netbsd.org/~ozaki-r/workqueue_drain.diff >>> (I will update workqueue.4 once the proposal is accepted.) >>> >>> And this is a patch that applies workqueue_drain to bridge(4): >>> http://www.netbsd.org/~ozaki-r/workqueue_drain-example.diff >>> >>> If we don't have workqueue_drain we had to add an extra >>> condvar to wait the workqueue worker of bridge to finish. >>> >>> Any comments or suggestions? >> >> >> You could add a new flag bit for WQ_DRAINING when you start to >> drain. Then workqueue_enque() could enforce the "no new work" >> with >> >> KASSERT_MSG((wq->wg_flags & WQ_DRAINING) != 0, >> "adding work to a draining workqueue") > > Good idea! > > I updated the patch: > http://www.netbsd.org/~ozaki-r/workqueue_drain.v2.diff
The implementation was not enough because workqueue_drain just waits for works to start, not finish. So to wait for completions, we need more changes like this: http://www.netbsd.org/~ozaki-r/workqueue_drain.v3.diff ozaki-r