Thread pool #3896
Thread pool #3896
Conversation
|
r+. Sorry for the delay. Didn't realize this was in my queue. |
|
The only thing this provides over a dedicated scheduler (assuming they become more efficient) is the local state. That seems like a useful enough feature, but isn't exactly what I think of when I think of thread pools. Maybe there's a better name for this that makes it clear that this isn't just a workaround for scheduler inefficiencies. |
|
This also doesn't consider what happens on failure. As written, the tasks are linked so failure of any task will result in failure of the entire pool. A more robust solution will surely have some additional nuance. Maybe a FIXME is warranted. |
|
Heh. Additionally, this is specifically designed for short tasks, not persistent tasks - if you try to schedule actor-style tasks with event loops here you will deadlock. Maybe something like |
|
I had another use case for this pattern. I think think servo may be able to parallelize selector matching, even with libcss, using a work pool. For my purposes though I think I want my tasks to be on the default scheduler, not dedicated threads. |
|
r+ |
# Conflicts: # src/bin/main.rs
… r=RalfJung ptr_offset_unsigned_overflow: extend test Test that indeed, the signed version works before the unsigned version is UB.
r? @brson
This is useful for Servo.