Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Consider worker virtualization layer #193
Timely has workers exactly mapped to threads, but we could have a virtualization layer so that threads can host multiple (or fewer) logical workers.
There are a few reasons to do this, none of which are especially new:
There may be some other reasons, who knows, but at least we should talk through what is required for this to happen.
Some more thoughts: it seems like nothing in the current timely interface exposes the concept of a "thread", but instead asks for per-worker logic. This logic has type
F: Fn(&mut Worker<Allocator>) -> ...
and so it should be instantiable multiple times, even in the same thread.
Now, this is actually a terrible idea, because the code is written as if a single thread that may spin on various resources, rather than one thread that may be driving multiple workers. Without some async/await magic, there isn't a great way to interrupt one of these closures and move to another on the same system thread. Having lots of actual system threads would be a bit of a departure from the current model (though, .. possible).
So, there may need to be a bit of a break in the way we structure these programs, either to patch in multiple workers underneath a call to