maatary (10) [Avatar] Offline
#1
I would like to understand what is mean here (in chapter 4):

“While an event-based system needs addressable event producers for registering callbacks, a message-based system consists of addressable consumers that can receive messages from potentially anonymous sources.”

What is the addressable event producer ? e.g. a Button ?

There was an analogy with node.js a bit before. I know Jquery so i will go with that, when in Jquery one does an Ajax call, register multiple call back. What is considered the addressable event producer ?




Another point made:

“It allows the event processing to proceed sequentially for individual consumers, enabling stateful processing without the need for synchronization; this translates down to machine level because consumers will aggregate incoming events and process them in one go, a strategy for which current hardware is highly optimized.”

I don't see how an event loop does not allow that. Event with there call back are queued. Event if two event work on the same shared object, it will never happen at the same time. This is because there only one thread of execution. Synchronization would be necessary if event callback could be executed by different threads.

I think this need to be clarified or better explained. But it should not be exposed as a gained provided by message passing over event loop. Unless i misunderstood it.

Many thanks

Maatari
roland.kuhn (39) [Avatar] Offline
#2
maatary wrote:I would like to understand what is mean here (in chapter 4):

“While an event-based system needs addressable event producers for registering callbacks, a message-based system consists of addressable consumers that can receive messages from potentially anonymous sources.”

What is the addressable event producer ? e.g. a Button ?

There was an analogy with node.js a bit before. I know Jquery so i will go with that, when in Jquery one does an Ajax call, register multiple call back. What is considered the addressable event producer ?


The addressable event producer may well be a button—it is the object on which you call “register” or “subscribe” or “onEvent” (or similar).

maatary wrote:Another point made:

“It allows the event processing to proceed sequentially for individual consumers, enabling stateful processing without the need for synchronization; this translates down to machine level because consumers will aggregate incoming events and process them in one go, a strategy for which current hardware is highly optimized.”

I don't see how an event loop does not allow that. Event with there call back are queued. Event if two event work on the same shared object, it will never happen at the same time. This is because there only one thread of execution. Synchronization would be necessary if event callback could be executed by different threads.

I think this need to be clarified or better explained. But it should not be exposed as a gained provided by message passing over event loop. Unless i misunderstood it.

Many thanks

Maatari


The cited machine-level advantage is that batching of message processing for each consumer or recipient will happen naturally in a message-driven system, leading to more efficient use of hardware caches and thereby fitting the design of current CPUs. In an event loop there is no correlation between different events affecting a single consumer and therefore these benefits are much harder to achieve—if not forbiddingly impractical.
Phil Derome (40) [Avatar] Offline
#3
fyi, I had the same confusion as mataary on his second point where R. Kuhn explains that the advantage of messaging over event loop is the batching of messages meeting hardware caches better. My confusion was that the statement offering an advantage for messaging spoke of stateful without synchronization and I was looking like Mataary for some shortcoming on the event loop side about being stateful for multiple events. So, ideally the several advantages for messaging could be broken down in separate sentences with the one specifically not available for event loop being singled out more explicitly. Well, it is probably too late for that now that the book is in print. This is more about a comment that two readers had difficulty at the same spot for the same reason and also a statement that this readers forum is useful to get a better understanding of the material of the book.