[dwattttt]

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"

[tialaramex]

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.

[loeg]

I work on a widely deployed (~11,000 servers and growing) piece of software that does not use any OS sleep/wake primitive for our MPSC queues -- just polling. It works really well with the right overall design.

[duped]

No it's not, that's the whole point of using polling.

[loeg]

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:

> Request-Response (planned)

https://docs.rs/iceoryx2/latest/iceoryx2/

[gpderetta]

Even with fire and forget, your send queue might become full. So you either drop the message of you have to wait for it to empty. Similarly on the receiving end you have to block waiting for the queue to become non empty.

In fact that's exactly the reason that async exists for networking.

[elfenpiff]

Here is one of the iceoryx2 maintainers, and we intend to implement request-response in Q3 this year.

[bfrog]

The signaling in this case is typically a shared atomic though not some OS primitive that a process can wake/epoll/etc on?

[elfenpiff]

In iceoryx2, we use something that we call event concept, which can either use unix-domain sockets so that you have something to select/wake/epoll on or a variant where we use a semaphore stored in shared memory. See: https://github.com/eclipse-iceoryx/iceoryx2/tree/main/iceory...

The unix-domain socket has the advantage that you can combine it with external non-iceoryx events, but you pay with a small performance hit. The semaphore event is usually faster. As a user, you can configure your IPC service architecture and use the mechanism that suits you best (but I have to admit that we have not yet documented this in detail). For the zero_copy service variants, it is done here: https://github.com/eclipse-iceoryx/iceoryx2/blob/main/iceory....

[loeg]

I believe you could do something with e.g. Linux futexes to support this kind of thing. But in general, polling at the receiver is going to be lower latency / higher throughput.