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.
7430: Simplify file download code r=matklad a=lnicola This avoids leaving the user with no LSP binary available if their network goes down during the download, and should not keep the current behavior: overwriting a running executable works on Unix and fails on Windows. It also removes the `overwrite` argument, which is always enabled and wasn't working anyway. Nominally closes rust-lang#3896 (although that's already fixed) Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
r? @brson
This is useful for Servo.