Question: Is running the task from schedule OK?

[vorner]

Hello

When browsing code around, I've came to wonder about one thing. What would go wrong, if I created a trivial „recursive“ executor by running the task directly inside the schedule closure? Eg:

let (task, handle) = async_task::spawn(future, Task::run, ());
task.run();

So far, this has crossed my mind:

• It'll probably make it run in whatever thread wakes the future (so the thread that polls timers or epoll or whatever), which might not be happy about the added latencies.
• Can the task get called recursively somehow?
• If so, doesn't that create two mut references to the future?

Or, are there any other problems or restrictions what the schedule closure can do?

[tmiasko]

I think that schedule function that does something significantly different from
sending a task through the channel is quite likely to be problematic. Even
dropping the task might be the cause of trouble, so sending through channel
should be infallible, (async-task design is not suitable for executors that
can be shutdown).

Why? Because schedule function is called primarily through wakers. Wakers in
turn are clonable and sendable, which means they can be woken up at arbitrary
point in time from an arbitrary thread. Wakers generally shouldn't call
arbitrary user code that wasn't explicitly designed for that purpose. Calling
other wakers is fine, but anything else requires careful consideration.

If you were to run task directly from schedule, then you will run into
situation where one task executes within another. The deadlocks are highly
likely, for example due to use of non-recursive mutexes. Panics are possible
due to conflicting borrows. In my experience most user code don't expect tasks
to be executed in such a manner.

Now, going back to the question of running the same task recursively and
obtaining two mut references to it. I don't think it is possible, and
asnyc-task prevents that from happening. If task is running it won't be
scheduled again before run completes. Nor will task be scheduled before
it had run.

[vorner]

I see, as this is a bad idea.

But, as there are quite strong recommendations what to (not) do inside the schedule function, would it make sense to include it somewhere in the documentation?