Variant on `join` that does not send closure `A`? about rayon HOT 7 CLOSED

First thing in join is to check if it's being called from outside the thread pool, and then it has to inject both closures, right? So I think a half-send version would have to be a separate call.

from rayon.

@cuviper ah, true. Good point.

from rayon.

Meh. Not worth it, I don't think.

from rayon.

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.

from rayon.

from rayon.

@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 Vec to keep track of all the things you forked.

from rayon.

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 Send things is probably ok for the most part.

from rayon.