Re: [seL4] Why send-only IPC doesn't and shouldn't return a success indicator

On 24 Sep 2016, at 19:30 , Matt Rice wrote:

Couldn't at the expense of an extra notification send, use a notification where the receiver of the notification then should call the then do a non-blocking reply. I didn't see reply being non-blocking described in the manual so please correct me if i am wrong.

This only works one party is willing to block correct, and there is no way to short circuit the call if an incoming message could be delivered to the call'ing process before the call can be completed? Although it would seem to take some amount of gymnastics to balance sending and receiving...

so if really neither are willing to wait there is always notifications+shared memory?

Typically it makes sense to block on the receive: - a client (using Call()) typically needs the server response to continue, and thus blocking makes sense - a server (using ReplyRecv()) does that because it has nothing else to do after serving one request than wait for the next. Any I/O completion would be signalled via a Notification that is bound to the server and delivered by the request endpoint Also, the server doesn’t care whether the client got the message, if it didn’t then it’s the client’s fault. Hence using NBReplyRecv() is generally the most appropriate operation for the server. If you want to be completely asynchronous, then a Notification-based protocol is the way to go. This would be the approach of choice if client and server are running on different cores. Gernot