Futures-rs: Does futures_cpupool still exist? (in futures 0.3)

[DCjanus]

Does futures_cpupool still exist in this repo? Or is there anything that can replace it?

[yoshuawuyts]

@DCjanus perhaps Juliex might fit your needs.

It has a spawn shorthand method that sets up a backing threadpool behind the scenes and just work.

And it has a Threadpool constructor that can come in handy when you need to setup thread-locals for your code.

[DCjanus]

Thanks! @yoshuawuyts

[DCjanus]

It seems that juliex does not cover all futures_cpupool usage.

For example, If I want to implement a async file IO library, and I don't want to use AIO in Linux, which means I have to put block tasks to a separate thread pool and await this task in main executor.

futures_cpupool provided a good abstraction for this: "await a Future in other executor".

[taiki-e]

CpuPool has been renamed to ThreadPool and incorporated to futures::executor (see https://github.com/rust-lang-nursery/futures-rs/commit/8198563d7aa970fda052f9d09e2837da89d062dc).

[laizy]

@DCjanus , I think what you want is spawn_with_handle, then the code use cpupool :

let result_fut = cpu_pool.spawn(long_running_future);

can be replaced with ThreadPool or juliex:

let result_fut = thread_pool.spawn_with_handle(long_running_future).unwrap();

[Nemo157]

Is futures::executor::ThreadPool appropriate to run blocking work on though? The purpose of futures-cpupool was a place to run blocking synchronous work and get a handle that will resolve with the result. As far as I'm aware futures::executor::ThreadPool is only intended as a very basic futures executor, which means it will likely be making tradeoffs targeted at running non-blacking asynchronous work.

EDIT: Although, looking at futures-cpupool's API it takes in Futures to run.... which doesn't make much sense to me... I think it would be good to have a goto thread-pool designed for turning a blocking FnOnce() -> T into a Future<Output = T> handle (when you're not known to be running on an executor like Tokio that provides its own similar abstractions).

[DCjanus]

@laizy Thanks for your help, spawn_with_handle is do helpful to me.

[DCjanus]

@Nemo157 My problem has been solved, but it seems that you have more thoughts about this.

If you think this issue could be done, please just close this issue; if you want to keep track this idea in this issue, maybe you want to keep this issue open.

[chpio]

Is futures::executor::ThreadPool appropriate to run blocking work on though?

It seem to have only one queue, that all threads are pulling tasks to run from. So a blocking task should not block other tasks. But is this guaranteed to be the case in the future or will it change? If so it maybe should be documented?

A task::SpawnBlocking trait for abstracting over tokio etc would be also nice to have.