Is it possible to define async functions in nanobind?

[tigrux]

I am creating a library of Actor Model in C++ and using nanobind for the Python bindings.
I blatantly copied the model of async promises of JavaScript.
I am using callbacks (one for success, another for failure).
Something like:

actor
    .send(message)
    .then( lambda value: on_value(value) )
    .fail( lambda error: on_failure(error) )

I later realized that by using a wrapper that provides __await__ I could rewrite it as:

value = await wrapper_with_await(actor.send(message))

For reference, here is the code of the wrapper:

class wrapper_with_await(object):
    def __init__(self, promise):
        self.value = None
        self.error = None
        self.resolved = False
        promise.then(self.on_value)
        promise.fail(self.on_fail)

    def on_value(self, value):
        self.value = value
        self.resolved = True

    def on_fail(self, error):
        self.error = error
        self.resolved = True

    def __await__(self):
        while not self.resolved:
            yield
        if self.error:
            raise RuntimeError(self.error)
        return self.value

Is it possible to create an async function directly from nanobind? Thanks.

[oremanj]

For most purposes, an async function in Python is interchangeable with a regular function that returns an awaitable object. You can write those in nanobind, but there aren't any nice interfaces currently for implementing them using C++ coroutines or similar; you need to either delegate to an existing awaitable object, or laboriously implement a state machine by hand.

Note that your example wrapper is extremely inefficient; it will use 100% CPU until the promise is resolved, because it just spins checking in a loop, yielding to other tasks but never going to sleep. You can make it better by integrating with your event loop's facilities for event notification; for example, if you're using asyncio:

def as_awaitable(promise):
    fut = asyncio.Future()
    promise.then(fut.set_result)
    promise.fail(lambda err: fut.set_exception(RuntimeError(err)))
    return fut

This is a synchronous function that returns an awaitable object. It's just adapting between your promise interface and asyncio's future interface. Call it like await as_awaitable(promise).

You can write a C++ version too:

nb::object as_awaitable(YourPromiseType& promise) {
    auto fut = nb::module_::import_("asyncio").attr("Future")();
    promise.then(fut.attr("set_result"));
    promise.fail([fut](const char* msg) {
        fut.attr("set_exception")(nb::borrow(PyExc_RuntimeError)(msg));
    });
    return fut;
}

[tigrux]

Thank you!

[tigrux]

@wjakob any comment please?

[breathe]

I'm trying to figure out a pattern for this as well.

I want to be able to author cpp functions that drop the gil, block an async task until the cpp operation completes but having dropped the gil allow other async tasks to continue running on the same python thread, and then signals back to the event loop appropriately so that the async task can continue after the cpp operation has completed. I'm using anyio currently with its asyncio backend implementation ...

Is this even possible to do? I'm not totally familiar with pythons async/await implementation... I guess maybe would need to implement the await protocol along these lines (?)

1. create the python task somehow
2. drop the gil
3. do the cpp operation
4. reacquire the gil
5. signal the python task somehow

I don't quite know how to spell that but wonder if Im aligned to the correct conceptual model of what's needed ...?

Right now Im using anyio's .to_thread(target) mechanism to turn the cpp callable (which drops the gil) into an awaitable object which calls the target method from another python thread. That means that the other python thread will have dropped the gil and block until the operation completes / reacquires the gil, basically using a python thread as a coroutine.

I think that's working -- tho I'm not 100% sure whether anyio guarantees that no other async task could get locked to the same worker thread running running the to_sync target and become blocked by it... also this arrangement is a little silly as the cpp operation internally does its heavy work on a separate thread which it owns anyway ... It feels like I should be able to collapse the layers and avoid some complexity and extra overhead (maybe) and be able to directly author awaitable cpp functions that play well anyio ...?