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

On Sat, Sep 24, 2016 at 11:21 PM, wrote:

...

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

.....

...

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

Typically it makes sense to block on the receive https://sel4.systems/lists/listinfo/devel

A consideration is buffer space and garbage collection. A reliable message needs to sit and sit until it is acknowledged. Unreliable messages can be made more unreliable with increased traffic. https://en.wikipedia.org/wiki/Sorcerer%27s_Apprentice_Syndrome Networking lets the OS toss the message onto the wire or air. The application or the OS could hold the message until the communication is acknowledged or a timer triggers. The application may know more than the OS so it is common to allow the application to manage the protocol. The need for speed pushes stuff into the kernel. IPC and communication protocols are difficult to get correct. My bias is a ring buffer (queue) in shared memory that uses dedicated cache lines so the sender and receiver can see and set messages and hints without conflicts. Volumes have been written that describe the good the bad and the ugly bits. http://www.dauniv.ac.in/downloads/EmbsysRevEd_PPTs/Chap_7Lesson12EmsysNewIPC... https://en.wikibooks.org/wiki/Operating_System_Design/Process Cleanup, exit, error handling, memory leaks, concurrency and security... -- T o m M i t c h e l l