Skip to content

Add PyFutureCallback type alias for the asyncio Future-resolving callback #1040

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Matt711 wants to merge 2 commits into
base: main
Choose a base branch
from
+9 −1
Open

Add PyFutureCallback type alias for the asyncio Future-resolving callback #1040

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
12c1a9f
Add PyFutureCallback type alias for the asyncio Future-resolving call…
Matt711 May 15, 2026
26e94af
Merge branch 'main' into imp/future-resolve-callback
Matt711 May 15, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 9 additions & 1 deletion python/rapidsmpf/rapidsmpf/streaming/_detail/libcoro_spawn_task.pxd
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,14 @@ cdef extern from * nogil:
#include <iostream>
#include <coro/task.hpp>

/**
* @brief Callback used to resolve a Python asyncio.Future from C++.
*
* Takes an opaque pointer to the Python Future and an optional
* null-terminated error message. NULL means success.
*/
using PyFutureCallback = void (*)(void*, const char *);

/**
* @brief Await a C++ coro::task and notify a Python asyncio.Future on completion.
*
Expand All @@ -34,7 +42,7 @@ cdef extern from * nogil:
* and the Python Future has been notified.
*/
coro::task<void> cython_libcoro_task_wrapper(
void (*cpp_set_py_future)(void*, const char *),
PyFutureCallback cpp_set_py_future,
Copy link
Copy Markdown
Contributor Author

@Matt711 Matt711 May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe AsyncIOFutureCallback?

Copy link
Copy Markdown
Member

@madsbk madsbk May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about cython_libcoro_task_wrapper_callback to avoid the name clash? Since this is in a .pxd, it will effectively be copy-pasted into all Cython files importing it.

Alternatively, we could wrap the whole thing in a namespace.

Copy link
Copy Markdown
Contributor Author

@Matt711 Matt711 May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about cython_libcoro_task_wrapper_callback to avoid the name clash?

Is there a current name clash or are you thinking of protecting against another .pxd using the same name with a different type?

Copy link
Copy Markdown
Contributor

@wence- wence- May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's put the whole thing in an anonymous namespace I think.

Although then I would worry about ODR-use violations...

Copy link
Copy Markdown
Member

@madsbk madsbk May 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a current name clash or are you thinking of protecting against another .pxd using the same name with a different type?

There is no current name clash. This is mostly about avoiding a future one.

Since this lives under _detail, we can always rename it later without a
deprecation period. Still, I think it is good style to use a unique name because this is
declared in a .pxd and may be pulled into different generated C++ files.

I do not think an anonymous namespace helps here. A cdef extern from * block
is effectively copied into the generated C++ source of each module that imports
it. So if a .pyx file also defines or imports a PyFutureCallback with a
different type, the names can still collide within that generated translation
unit.

That is why I prefer a more specific name like cython_libcoro_task_wrapper_callback.

rapidsmpf::OwningWrapper py_future,
coro::task<void> task
) {
Expand Down
Loading