On Sat, Sep 24, 2016 at 11:21 PM, <Gernot.Heiser@data61.csiro.au> wrote:

> On 24 Sep 2016, at 19:30 , Matt Rice <ratmice@gmail.com> 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

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.pdf

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