For some workloads many tasks are spawned at a time. This requires
locking and unlocking the executor's inner lock every time you spawn a
task. If you spawn many tasks this can be expensive.
This commit exposes a new "spawn_batch" method on both types. This
method allows the user to spawn an entire set of tasks at a time.
Closes#91
Signed-off-by: John Nunley <dev@notgull.net>
It turns out that with the current strategy it is possible for tasks to
be stuck in the local queue without any hope of being picked back up.
In practice this seems to happen when the only entities polling the
system are tickers, as opposed to runners. Since tickets don't steal
tasks, it is possible for tasks to be left over in the local queue that
don't filter out.
One possible solution is to make it so tickers steal tasks, but this
kind of defeats the point of tickers. So I've instead elected to replace
the current strategy with one that accounts for the corner cases with
local queues.
The main difference is that I replace the Sleepers struct with two
event_listener::Event's. One that handles tickers subscribed to the
global queue and one that handles tickers subscribed to the local queue.
The other main difference is that each local queue now has a reference
counter. If this count reaches zero, no tasks will be pushed to this
queue. Only runners increment or decrement this counter.
This makes the previously instituted tests pass, so hopefully this works
for most use cases.
Signed-off-by: John Nunley <dev@notgull.net>
After smol-rs/async-task#37 I meant to add this to the executor. This
commit makes it so all panics are surfaced in the tasks that the user
calls. Hopefully this improves ergonomics.
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: Alain Zscheile <fogti+devel@ytrizja.de>
* Fix a bug where TLS would become None
The bug is invoked as follows:
- Runner 1 is created and stores the current version of the TLS
LOCAL_QUEUE variable, which is None.
- Runner 2 is also created. It stores the current version of the TLS
variable as well, which is Runner 1's queue.
- Runner 1 is dropped. It stores None into the LOCAL_QUEUE variable.
- Runner 2 tries to run. It reads from the LOCAL_QUEUE variable, sees
that it is None, and panics.
This could be solved by just not using the local queue if the variable
is None. However, we can do one better; if the slot is open, we can
optimize the runner by replacing it with our own queue. This should
allow for the local queue to be used more often.
Closes#54
Signed-off-by: John Nunley <dev@notgull.net>
John Nunley
Taiki Endo
Stjepan Glavina