Re: workqueue_drain

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Fri, Dec 22, 2017 at 4:12 PM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
> On Thu, Dec 21, 2017 at 5:56 PM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>> On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst <mlelstv%serpens.de@localhost> wrote:
>>> ozaki-r%netbsd.org@localhost (Ryota Ozaki) writes:
>>>
>>>>On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst <mlelstv%serpens.de@localhost> 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