Re: workqueue_drain

On Fri, Dec 22, 2017 at 4:12 PM, Ryota Ozaki wrote: > On Thu, Dec 21, 2017 at 5:56 PM, Ryota Ozaki wrote: >> On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst wrote: >>> ozak...@netbsd.org (Ryota Ozaki) writes: >>> On Wed, Dec 20,

Re: workqueue_drain

On Thu, Dec 21, 2017 at 5:56 PM, Ryota Ozaki wrote: > On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst wrote: >> ozak...@netbsd.org (Ryota Ozaki) writes: >> >>>On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst wrote: What about a

Re: workqueue_drain

On Wed, Dec 20, 2017 at 5:41 PM, Ryota Ozaki wrote: > On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette 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

Re: workqueue_drain

On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst wrote: > ozak...@netbsd.org (Ryota Ozaki) writes: > >>On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst wrote: >>> What about a method that waits for a specific work to complete? > >>It might be useful but

Re: workqueue_drain

On Thu, Dec 21, 2017 at 05:32:58AM +0800, Paul Goyette wrote: > I'm not totally convinced here. It might be useful to wait for a > particular work to be finished in order to allow it to be enqueued > again (no work can be enqueued if already in the queue). But I don't > see how "remember the

Re: workqueue_drain

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".

Re: workqueue_drain

On Wed, 20 Dec 2017, Michael van Elst wrote: ozak...@netbsd.org (Ryota Ozaki) writes: On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst 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

Re: workqueue_drain

ozak...@netbsd.org (Ryota Ozaki) writes: >On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst 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

Re: workqueue_drain

On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst wrote: > ozak...@netbsd.org (Ryota Ozaki) writes: > >>Here is a patch: >> http://www.netbsd.org/~ozaki-r/workqueue_drain.diff >>(I will update workqueue.4 once the proposal is accepted.) > > What about a method that waits for

Re: workqueue_drain

ozak...@netbsd.org (Ryota Ozaki) writes: >Here is a patch: > http://www.netbsd.org/~ozaki-r/workqueue_drain.diff >(I will update workqueue.4 once the proposal is accepted.) What about a method that waits for a specific work to complete? -- -- Michael van Elst

Re: workqueue_drain

On Wed, Dec 20, 2017 at 5:41 PM, Ryota Ozaki wrote: > On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette 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

Re: workqueue_drain

On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette 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

Re: workqueue_drain

On Wed, 20 Dec 2017, Paul Goyette wrote: KASSERT_MSG((wq->wg_flags & WQ_DRAINING) != 0, "adding work to a draining workqueue") And, of course, that should have been ==, not != :) +--+--++ | Paul Goyette

Re: workqueue_drain

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