Gernot.Heiser wrote: > We have just received this comment on github, which I think merits some > explanation: >> There are times when IPC needs to happen, but a sending process cannot wait >> around for another process to be receiving. seL4_NBSend is basically the >> system call for this, but it never provides any feedback whether or not IPC >> took place.
... >This gets me to (2): send-only IPC is the wrong way to solve the problem. > >The above use case is clearly one where info flow is inherently two-way: you >send >something and need an acknowledgment of > receipt. This means call-type IPC is the right mechanism, it does exactly > that. And on top of that it is more efficient than > separate send-receiver, and avoids (thanks to reply caps) the need to set up > a separate reply channel. New to sel4 and the list (so sorry for stuffing up the threading) 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? _______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
