scope without Send

[jonhoo]

This ties somewhat into the discussion over in #522 (comment).

Currently, ThreadPool::scope requires the passed closure to be Send because the closure itself is executed on the thread pool. However, if ThreadPool is used as a more generic thread pool (rather than explicitly for data-dependent computation), it is not unreasonable for some existing thread to wish to spin off a number of jobs with access to its stack, and then wait for them all to complete (essentially as a pool of scoped threads). With the Send bound in place, that thread is pretty restricted in what it can use to generate jobs (e.g., anything with Rc is a no-go). It'd be good if there was an alternate version of scope that did not require Send for its closure, and which instead executed the closure on the current thread (but still waited for any spawned jobs to complete).

[cuviper]

I expect it's possible, but I'm not sure that we should.

One reason that we enter the threadpool for scope is so that its calls to spawn can push directly to a local job queue. Pushing to the global queue requires taking a lock. But maybe that synchronization wouldn't be a big deal for some use cases.

[alecmocatta]

I just bumped into this. I'm using scoped_threadpool as well as rayon and noticed the latter ostensibly contained the former's functionality, enabling me to unify on one threadpool. Unification would be convenient as I want a thread per core, and ensuring that over two independent threadpools is nontrivial (given I wouldn't want cores to be idle if one threadpool was full but one empty).

[rocallahan]

I bumped into this too. https://github.com/reem/rust-scoped-pool is unmaintained so I'm trying to migrate to rayon's ThreadPool and in some places that doesn't work because the scope closure is not Send (and making it Send requires significant API changes in callers).

@cuviper

Pushing to the global queue requires taking a lock. But maybe that synchronization wouldn't be a big deal for some use cases.

What if we used MsQueue for the global queue and avoid the lock?

Alternatively, I'm considering implementing a new Deque that supports push/pop/steal/steal_half, implements Sync, and doesn't separate workers and stealers. The intended use case for it is shared global deque of tasks, which is not owned by any worker thread.

[cuviper]

What if we used MsQueue for the global queue and avoid the lock?

It's worth trying!

[cuviper]

FWIW, #615 is changing the global queue to a SegQueue (without a lock), so we could follow up by experimenting here without an initial Send.

[abonander]

I've run into a need for this in #676.

[DzmitryFil]

+1 for this, Send requirement is very restrictive in some cases. I work primarily with webassembly, and none of the web api's are capable of working across different threads (!Send), which severely limits rayon usage. Scope without Send would allow me to do useful work on the worker thread with !Send stuff (inside scope closure), while at the same time running rayon jobs in scope. Currently i have to choose, either i make some progress with !Send stuff on the main thread, or i run rayon scope/join.

[rocallahan]

I hacked together a version of this here: https://github.com/rocallahan/rayon/commits/downstream

Apart from eliminating the Send bound on the OP closure it's a bit more efficient because you don't need to send the op across threads, when you're not already on a worker thread. Also, the op can safely wait for spawned closures to complete; with regular scope, you can't, because blocking a worker thread on spawned work can deadlock.

Should I clean it up and submit it?