> On May 5, 2015, at 1:51 PM, Matthew Ahrens <[email protected]> wrote:
>
> I take this to mean taskq callbacks should not call taskq_dispatch()? What
> is your concern here and do you have a suggestion of how to implement what
> Arne is trying to do? I could see creating our own queue of things to do,
> but if managed similarly (adding things to the queue from the cb) I'm not
> sure how it's substantively different.
>From the man page:
The ddi_taskq_destroy() function waits for any scheduled tasks to
complete, then destroys the taskq. The caller should guarantee that no
new tasks are scheduled for the closing taskq.
The ddi_taskq_wait() function waits for all previously scheduled tasks
to complete. Note that this function does not stop any new task
dispatches.
So it appears neither call has safety for new tasks being added to the queue.
Consider this simple tree:
a
| |
b c
| | | |
d e f g
So we enter and schedule 'a', which completes after scheduling 'b' and 'c'.
'a' returns, and we taskq_wait(). Tasks 'b' and 'c' will SCHEDULE 'd' through
'g', but then return, and if I understand the man page, taskq_wait() will
return once 'b' and 'c' (and ONLY 'b' and 'c' as "previously scheduled tasks")
are done.
If the man page is wrong, and that taskq_wait() will wait until the whole
damned taskq is EMPTY, even if existing tasks add new ones, than my objection
is moot, modulo perhaps a man page bug to explain this more clearly.
Dan
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
