Hi Tejun, On Fri, Feb 8, 2019 at 12:07 PM Tejun Heo <[email protected]> wrote: > > I don't object to the basic idea but cancel_[delayed_]work_sync() > works iff queueing is disabled already, so there can be situations > where this can lead to surprising / subtle failures. Given that, it > *might* not be a bad idea to keep this explicit unless there is a way > to reliably block future queueing. >
Yes, I'm "coming around" to your opinion myself. There's also the question of which one is appropriate for clean-up: cancel_work_sync() or flush_work(). And what about work scheduled on more than one workqueue? Or work scheduled on multi-threaded workqueues? The workqueue API sounds too complicated to have a devm_ helper. It would lull developers into a false sense of security.
