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 last work enqueued and wait for it to be done > before destroying" is more versatile than "waiting for all to be done > before destroying". It certainly seems that the latter is a simpler > approach.
Given that you have to make the workqueue externally non-accessible first anyway, the former provides all the functionality of the latter. If you don't make it unaccessible first, you always have a race condition. Joerg
