tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: workqueue_drain
On Wed, Dec 20, 2017 at 5:41 PM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
> On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette <paul%whooppee.com@localhost> 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
Home |
Main Index |
Thread Index |
Old Index