Future panics if it was polled immediately after it was submitted to the CpuPool

[dovahcrow]

This snippet of code reproduces the panic.

extern crate futures;
extern crate futures_cpupool;
use futures::Future;
use futures_cpupool::CpuPool;

fn main() {
    let f = futures::lazy(|| Ok::<u32, u32>(1));
    let pool = CpuPool::new(1);
    let mut c = pool.spawn(f);
    let _ = c.poll();
}

[dwrensha]

Yep, when I run that code I get the error message:

thread 'foo' panicked at 'no Task is currently running'

The problem is that Future::poll() is only allowed to be called from a task, because it needs to be able to arrange to be called later if it's not currently ready. (#250 and #136 have some discussion about how this kind of thing can be confusing.) Typically poll() is used in implementations of the Future trait, but not in higher level code.

If you don't need to do any async I/O, then Future::wait() might be sufficient for your needs. It handles creating a task on which to run a future:

    let f1 = futures::lazy(|| Ok::<u32, u32>(1));
    let f2 = futures::lazy(|| Ok::<u32, u32>(2));
    let pool = CpuPool::new(1);
    let mut c1 = pool.spawn(f1);
    let mut c2 = pool.spawn(f2);
    println!("{:?}", c1.join(c2).wait());

If you are going to need to do async I/O, then you'll need some way to manage tasks that are waiting on external events. The easiest path forward in that case is to add a dependency on the tokio-core crate and launch a tokio_core::reactor::Core.

[alexcrichton]

I think @dwrensha hit the nail on the head, so closing in favor of the linked issues.

[dovahcrow]

@dwrensha then how do I know a task is finished and get the result outside the worker thread of CpuPool if I'm using the async way? I currently using code like this to check if a future is resolved and send the result to elsewhere in my main thread:

// push the future 
fn push_futures(&mut self, fut: BoxFuture<HQMessage, Error>) {
        let fut = self.future_pool.spawn(fut);
        self.pending_futures.push(fut);
}

// see if they are finished
fn resolve_futures(&mut self, cli: &mut RtmClient) {
        let unresolved: Vec<_> = self.pending_futures
            .drain(..)
            .filter_map(|mut fut| {
                if let Ok(Async::Ready(HQMessage(channel, user, text))) = fut.poll() {
                    let _ = cli.send_message(&channel, &format!("<@{}> {}", user, text));
                    None
                } else {
                    Some(fut)
                }
            })
            .collect();
        self.pending_futures = unresolved;
    }

[Diggsey]

@alexcrichton I think there's a legitimate use-case here which is not currently supported (or at least not easy): the ability to check whether a future is complete without setting up any unpark events. (Say your main thread is running a real-time application rather than an event-based one).

At the moment the way to do this is to spawn the future, and then poll the spawned future, passing in a dummy Unpark value.

[dovahcrow]

yeah, after looked into the source code, thats how I solved this problem.

On Sun, 1 Jan 2017 at 11:43 PM Diggory Blake ***@***.***> wrote: @alexcrichton <https://github.com/alexcrichton> I think there's a legitimate use-case here which is not currently supported (or at least not easy): the ability to check whether a future is complete without setting up any unpark events. (Say you have a real-time application rather than an event-based one). At the moment the way to do this is to spawn the future, and then poll the spawned future, passing in a dummy Unpark value. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#289 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA88zry9Gte-Ran6GYX8gI9s0sw4ETQsks5rN8mygaJpZM4LLcwW> .

-- Young Wu *Data Scientist* Data Team, Strikingly a: 248 Daxue Road, Yangpu District, Shanghai w: wooya.me e: [email protected] <https://cn.linkedin.com/in/wooya>