Stiffstream / sobjectizer

An implementation of Actor, Publish-Subscribe, and CSP models in one rather small C++ framework. With performance, quality, and stability proved by years in the production.

Home Page:https://stiffstream.com/en/products/sobjectizer.html

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

handle_n for mbox?

ilpropheta opened this issue · comments

Hi,
what is your recommended practice to wait for getting exactly N messages from a mailbox? Imagine something similar to handle_n for message chains. I think I have read something about on the wiki but I cannot remember where...

Many thanks.

Marco

Hi!

There are two different cases:

  1. You have to sequentially handle N incoming messages and only then do something. There is no out-of-the-box solution to that task. You have to count handled messages by yourself.
  2. You have to collect N incoming messages and only then do something with them. In that case, you can take a look at so_5::extra::mboxes::collecting_mbox.

Thanks! The second scenario is what I need and I will have a look at collecting_mbox.

I have another related question and I would like to share a bit of the context.

I have an application that grabs images from a camera and sends them to one mailbox. Some agents can subscribe to this mailbox and process the stream of images independently. A classical SPMC scenario. For instance, one agent can save the stream to the disk, another one can perform some statistics on the pixels, etc. This works nicely:

Grabber -> mbox
              <-- agent 1
              <-- agent 2
              <-- agent 3
              <-- ...

Now, suppose I want to add an agent that sends the frames to VLC. VLC works via callbacks, in "pull" mode. Roughly speaking, it calls some of my functions when it wants to read the next image. I cannot simply send them across*.

A simple approach is to use a message chain and call handle_n(1) from the read callback. However, to get the stream of images, I need an agent in the middle that subscribes to the image mailbox and just copies the traffic to the chain (a sort of "parrot" agent):

Grabber -> mbox
              <-- agent 1
              <-- agent 2
              <-- agent 3
              <-- parrot agent --> mchain <-- VLC agent <-- VLC

Although writing that parrot agent requires just a few lines of code, I am wondering if SObjectizer (or SObjectizer extra) can do something already. In other words, I am wondering if a message box (or message chain) can subscribe to another message box (!).

This would save not only extra code to maintain, but also hosting that parrot on some cooperation (that could take some resources, especially if the number of parrots increases in the future). Also, the parrot now handles just one message type but it might need to redirect more and this would result in adding more code to maintain.

As a side note, so5extra's fixed_mbox could work by changing the design of the application:

Grabber -> fixed_mbox
                    so_direct_mbox <-- agent1
                    so_direct_mbox <-- agent2
                    so_direct_mbox <-- agent3
                    mchain <-- VLC agent <-- VLC

However, it forces me to know in advance the agents that want to subscribe and it also does not allow me to use the great "named mailbox" feature.

Please let me know your thoughts.

Many thanks.

  • just for completeness, VLC can work with pipes (or stdin), in push mode. However, I cannot exploit that feature in my scenario.

I am wondering if SObjectizer (or SObjectizer extra) can do something already. In other words, I am wondering if a message box (or message chain) can subscribe to another message box (!).

No, there is no such feature for now. I thought about such a possibility several times but it never got implemented :(

As a workaround you can make your own mbox by implementing so_5::abstract_message_box_t interface (by using proxy_mbox as the basis). That mbox can hold an actual MPMC mbox under the hood + mchain or something else. In the do_deliver_message of your custom mbox you just call do_deliver_message methods of the underlying MPMC mbox and your mchain.

Ok, thanks for your suggestions!