Is shared memory access naturally async like IO/io_uring? If not, asking for async is misplaced and any implementation would be synonymous with wrapping sync calls in `async fn` wrappers.
I think it's as naturally async as anything else here actually. If you're calling a function via IPC over shared memory, you're sending a message, signalling it's there to the other process, and waiting for a response message with the result.
The only thing needed to turn this async is to change the "get result over IPC" function from "block until result is available" to "check if result is available, return TRY_AGAIN if it's not"
In practice it's not desirable to go without an explicit wake feature, we need some way to know that now it's likely to succeed. The mechanism needn't be 100% reliable but "Always try again" is essentially exactly as useless as blocking.
The core primitive for IPC isn't "request and wait for a response," it's "send a single message and return immediately." Sure, if you want an RPC framework over IPC, maybe you want async blocking, but that's sort of a higher level concern than basic IPC.
It seems that iceoryx2 intends to support request-response in the future, but doesn't today:
dwattttt|1 year ago
The only thing needed to turn this async is to change the "get result over IPC" function from "block until result is available" to "check if result is available, return TRY_AGAIN if it's not"
tialaramex|1 year ago
loeg|1 year ago
It seems that iceoryx2 intends to support request-response in the future, but doesn't today:
> Request-Response (planned)
https://docs.rs/iceoryx2/latest/iceoryx2/
bfrog|1 year ago