-
Notifications
You must be signed in to change notification settings - Fork 779
[RFC] Add support for C++26 std::execution #655
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.
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
base: master
Are you sure you want to change the base?
Conversation
Thanks. I think some of these can be separate PRs, like the CPM and vcpkg changes. I have never used senders so it's a bit hard for me to review. But about the thread-safety: can multiple tasks send/receive messages/multipart messages at the same time (executing in a single threaded context)? |
No. because multiple wake up (from the stream_descriptor wait_read / wait_write) are scheduled at the same time. For example if both A and B are sending multipart from the same ROUTER socket (where the first message is the routing_id). There are two pending multipart messages to be sent:
Assuming A queued "Hello" (SNDMORE) into the send queue and the queue is full, A will be suspended and wait for file descriptor's ready write signal. This should be rare, but still possible (for example if the server is sending messages too fast, faster than the clients can handle). I think the comment can be updated to use term "concurrent unsafe" rather than "thread unsafe". I looked at the native Rust implementation (which has async support) and it also has the same restriction at the exposed interfaces. read/write interfaces take mutable references which basically means it's not allowed to read/write the same socket concurrently (as Rust only allows single mutable reference to exist at a time). Other than the "don't do anything" approach. There are two sane ways to address it:
Both will slow down all read/write operations, as more synchronization efforts are required (single message send also needs to not intervene with multipart message send).
I agree. I will remove them later. By the way the CI is failing as it doesn't have Boost library. I'm still hesitant if Boost.Asio should be used here (hence the PR was marked as draft, and the interface is placed inside On the other hand, the alternate approach would be to either ask libzmq to expose asynchronous interfaces as C API like nng does (API ref), or have me implement my own in-house event loop (which I sadly can't do better than the existing, battle-tested Asio), or not have coroutine/async support in cppzmq at all (which I think is also bad). |
wishlist (from libzmq): provide asynchronous APIs that allow me to:
If these are possible, then cppzmq can gain async/coroutine support using only libzmq. the entire abstraction of coroutines are built on top of callbacks anyway. [1] A multipart message containing only a single message is also a multipart message. *I'm basically asking for Windows IOCP style APIs. |
Alternative to #653.
Note: