How to execute future immediately instead of waking task?

[liang-kang]

For a simple delay example here:

struct Delay {
    when: Instant,
}

impl Future for Delay {
    type Output = ();
    fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<()> {
        if Instant::now() >= self.when {
            Poll::Ready(())
        } else {
            let waker = cx.waker().clone();
            let when = self.when;

            // Spawn a timer thread.
            thread::spawn(move || {
                let now = Instant::now();
                if now < when {
                    thread::sleep(when - now);
                }
                waker.wake();
                // TODO: 
                // execute delay future here instead of wake the async future task
            });
            Poll::Pending
        }
    }
}

Normally inner time thread should wake up the delay future task, and then releated task will be scheduled at least once somewhere.
But such scheduling is not efficient for a very high performance case. A mode of "Run to Complete" is much more efficient.
So is there any way to immediately execute such delay future task just in time thread instead of waking up and scheduling to execute somewhere?

[Darksonn]

No, you cannot schedule a spawned task outside the runtime.

[Noah-Kennedy]

@liang-kang I think you are misunderstanding how futures work.

I would recommend that you read this post here: https://fasterthanli.me/articles/understanding-rust-futures-by-going-way-too-deep

Also, in the example here you are spawning a thread to do background work rather than using the tokio time APIs, which are backed by OS APIs like epoll which are designed for asynchronous systems, which would be more efficient. A huge part of why async is more efficient is that you can do more with fewer threads, and skip out on a lot of overhead. What I am getting at here is that even if what you were proposing was doable, it would still be a bad idea.

[liang-kang]

@Noah-Kennedy thanks for your reply.

The example is only for a demonstration.

Actually, I am trying to write a RDMA program with rust async/wait primitive.

I take use of tokio::spawn to create 2 tasks to get the event from RDMA cq with AsyncFd.
And also create several tokio tasks to handling the request.

One RDMA cq task gets event to create a request and then send to request task for handling.
For currently testing, request task does nothing but sending rdma response back.
The other RDMA cq task get event of response ack and wake up the request task to finish.

Such RDMA implemetation is the same as C language with OS thread, except that OS thread finishes the request directly.

With C implemetion, much more parallelled requests can be handled per second with lower CPU utililization.

So I doubt that the scheduling may affect the performance.