Re: [PATCH] workqueue: rust: add creation of workqueues

From: Philipp Stanner
Date: Thu Apr 17 2025 - 03:23:08 EST


On Wed, 2025-04-16 at 09:57 -1000, Tejun Heo wrote:
> Hello, Alice.
>
> On Wed, Apr 16, 2025 at 09:41:21PM +0200, Alice Ryhl wrote:
> ...
> > I thought about implementation approaches. The first thought that
> > sprang to mind is add a list of all delayed work items, but now I
> > think we can do better. We can have an atomic counter tracking the
> > number of delayed work items, and have destroy_workqueue() do this:
> >
> > retry:
> > drain_workqueue(wq);
> > if (has_delayed_work_items(wq)) {
> >     wait_for_delayed_to_be_scheduled(wq);
> >     goto retry;
> > }
> >
> > where wait_for_delayed_to_be_scheduled() either waits for the
> > counter
> > to hit zero, or waits for at least waits for one of them to be
> > scheduled. For example, maybe wait_for_delayed_to_be_scheduled()
> > could
> > add a dummy work item *without* waking up the worker threads, and
> > then
> > wait for that work item to get executed, which would effectively
> > mean
> > that it sleeps until something else wakes up a worker.
>
> I suppose that can work too but the delays can be pretty long, so
> while
> correct, I'm not sure it'd be very pleasant to use. If we per-cpu
> lists, I
> don't think the overhead would be all that noticeable, so may as well
> do
> that?

I assume you, ultimately, mean that the list of delayed_work's would be
accessible through workqueue_struct, correct?

And then destroy_workqueue() could loop over all of them with
cancel_delayed_work_sync()?

I think that would be the cleanest possible solution.

P.

>
> Thanks.
>