Best practice to pass a ThreadPool

help
1

Suppose you have a number of methods that needs a rayon ThreadPool to perform computation in parallel. The ThreadPool specifies the amount of parallelism. You will be calling several of these methods.

I see two options:

  • Each method has an argument of type &ThreadPool. This argument can be used or passed to other methods without further processing, but if the method returns a value it will be impossible to pass a references to a temporary ThreadPool created on the fly, forcing the caller to define a variable containing the thread pool only for the purpose of passing a reference,.
  • Each method has an argument of type Borrow<ThreadPool>. The argument can be owned, or borrowed, or even created on the fly, but now the function has to use thread_pool.borrow() to access the pool (an initial let thread_pool = thread_pool.borrow() will suffice), the only exception being when the argument is passed exactly once to another similar method.

Essentially, the first solution might require a bit more work from callers if they need to create a thread pool on the fly. The second solution makes it possible to pass thread pools created on the fly, but imposes a little burden on the callee.

Is there an idiomatic choice here? Or it is just a matter of personal taste?

1 Like
2

Using &ThreadPool is definitely more idiomatic. Asking callers to add an extra ampersand is not really more work from the caller.

2 Likes
3

No, that is not sufficient if you are creating the thread pool on the fly and you use the result of the method. See here. You have to use let to create a variable, store the pool there, and then pass a reference to the variable.

This is a generic problem, not a problem with thread pools.

4

Assuming the return value of the function has a reference to the pool, sure. Still, &ThreadPool is the idiomatic way because then the alternative is even worse since the return value now has to be generic over whether the threadpool is borrowed or owned.

2 Likes
5

Right. I had missed the fact that the problem with & happens only when the result has a reference to the thread pool.

1 Like