Thanks also for the question about the synchronous request-reply communication. In a traditional sequential programming this is the most basic communication style corresponding to a function call (or perhaps a remote procedure call–RPC). The caller simply blocks until the function returns. Seems clean, but it really sweeps tons of issues under the rug. The question, of course, is what happens between the call and the return.

The event-driven programming paradigm without blocking exposes the in-between. (So yes, the originator of the request indeed returns to the main loop, as *always*.) Without blocking, you explicitly have to do something between an asynchronous request and the asynchronous reply. (I assume that the recipient of the asynchronous request knows that the reply is expected.) So, in real life, the producer of the asynchronous request transitions to a special “waiting-for-reply” state. The behavior in this state could be to ignore all events except the expected reply, but often you will find out that some events in-between should be actually handled. And this is exactly the beauty of event-driven programming. Because you don’t block, you actually *can* handle some events in-between.

In contrast, when you program sequentially, you lose the whole blocked task for the whole duration of the RPC call and you end up inventing another task that is alive and can handle some critical events that arrive in-between. This is how the real mess begins, because now the second task needs to likely access the same data that the first task is operating on, so the whole issue of mutual exclusion comes into play. Mutual exclusion causes more blocking, and so the vicious cycle begins.

The generic task_routine you present seems very elegant, but I’m curious to know how you handle the case when the event handler needs to query another task, i.e. if it cannot continue processing until it gets a reply to a message.
It could return back to the main event loop to wait for the reply but then that would require saving state somewhere and adding another event type for the event handler to handle, which could easily get very messy.

Do you have any tips for this kind of situation?

I just start working for nearly 2 years for a small company outsourcing embedded (mobile) software. I’ve done my Master degree in Quantum optics, and have been still in love with QM. That why I was so excited when found out you and your book. I also have a deep belief in the meaning of the “State” concept even in this old-fashion industry.

I’m planning to learn your idea to my best and try to apply it for making a simple hypervisor. I’m not sure whether it is possible. But it’s a long road ahead of my career, I have a lot of time to try it