Variant on `join` that does not send closure `A`?

[nikomatsakis]

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.

[cuviper]

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.

[nikomatsakis]

@cuviper ah, true. Good point.

[nikomatsakis]

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

[nikomatsakis]

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.

[cuviper]

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.

[nikomatsakis]

@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.

[nikomatsakis]

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.