-
Notifications
You must be signed in to change notification settings - Fork 487
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Variant on join
that does not send closure A
?
#20
Comments
First thing in |
@cuviper ah, true. Good point. |
Meh. Not worth it, I don't think. |
join
does not need to be sendjoin
that does not send closure A
join
that does not send closure A
join
that does not send closure A
?
OK, I decided to reopen, but changed the title. It seems like there might be some use for this. The idea would be that sometimes you want to do work on the "main" thread while also doing parallel processing in parallel. Use case is the SDL-based visualizer in the nbody demo, where it'd be nice to assemble the frame in parallel with computing the next one. You can certainly do this with Rayon's existing join, but I think one is only supposed to do certain tasks from the "main" thread. Another use case would be anything that requires thread-local data. But I agree with @cuviper that this seems to be a distinct thing from the simple join, so maybe it would require a separate function. Or maybe we can rework join so that it's fine there. I don't know, but I'm going to leave it open as something to think about as a future enhancement. |
Maybe you just need something like a "future" for a single closure? Inject
the job and return the `Latch` (possibly wrapped) to let you wait for it
later.
|
@cuviper yes, but it would need a join scope of some kind in order to access borrowed data. So basically you could imagine adding an API like: join_scope(|scope| {
scope.fork(|| ...); // can call as many times as you want
});
// forked things are done now Behind the scenes, this would need some sort of |
I think I'm just going to close this. It might be handy, but ... meh. We have scope now and I think concerning ourselves with |
Since we are guaranteed to execute closure A on the main thread, it occurs to me that it does not really need to be
Send
. Lifting this restriction would add a bit of flexibility. For example, one could thread some non-thread-safe data through the first closure, spawning tasks with the right closure. (Though you'd still have to write tasks in a kind of recursive style.)UPDATE: This doesn't quite work, but see this comment.
The text was updated successfully, but these errors were encountered: