Comments (2)
Personally I have no problem with the current situation. But it may be because I usually have access to source code of agents in a project. Perhaps if I work with a big project that is split into separate closed-source subprojects developed by separate teams and the only way to get information about the subprojects' interfaces is through the documentation and header files with message declarations... But there haven't been such cases in SObjectizer history yet :)
However, there were a couple of discussions in the past that were related to this topic.
If I remember correctly the first one was about understanding an agent's logic: which messages it receives, in which states, which state transitions the agent performs... One of my colleagues in the mid 2000s even proposed a notation for describing messages/states. But it wasn't used (I don't remember why, but can suppose that it's because such description wasn't in sync with the source code).
So the first part of the problem is how to quickly observe what messages an agent receives and how it handles them.
There are no tools or recipes that allow it. The only way now is to look at the agent's source code. But I hope that the use of so_define_agent
(no subscriptions outside of so_define_agent
if possible), states as members of agent class (no dynamically created instances of so_5::state_t
) and event handlers that accepts mhood_t<T>
makes that task a bit easier.
I didn't think much in this direction and it seems that there is no simple way to simplify that task without creation of some external tool (somewhat similar to Doxygen) that will parse C++ source code and extracts SObjectizer-related information like states, subscriptions for every state, state transitions and so on. I know that the LLVM project makes creation of such a tool possible, but I have never dug into that topic.
Another discussion was about a strict description of the message types that can be sent to a given mbox. It could be seen as a contract for an mbox that is expressed in C++ source code in some way. For example, we can declare that mbox A can only receive msg_1 and msg_2, and mbox B can only receive msg_2 and msg_3. An attempt to send a message of type msg_3 to mbox A (or an attempt to subscribe to a message of type msg_3 from mbox A) should fail (preferably at compile time).
It's an interesting topic and I even did a simple sketch of how it can looks like (in Russian): https://eao197.blogspot.com/2017/03/prog.html
But this topic was not developed further.
One reason was the absence of the real demand for such a functionality. It's interesting to speak about a fancy feature, but it's hard to find someone who really needs it and can help in designing and testing it in the field :(
Another reason is the loss of flexibility provided by untyped mboxes.
For example, we can have an mbox A that is used for distributing messages M1 and M2. Everything is going fine until we've encountered some bug and want to find it. Sometimes we have to send some additional message M3 to that we write a special handler that helps us understand the behavior. Once we find and fix the bug, we remove M3 and its handler.
Untyped mboxes allow such an approach easily. But if the mbox A is a typed one then we have to change its contract, rebuild a part of projects, then return the original contract for A and rebuild another time. And the changing of the mbox A can be difficult if that mbox is described in a library we don't own (for example that library is written by a separate team as a part of work on a separate subproject).
Such a scenario can be considered exotic, but I have used it sometimes.
However, if the project involves for a long time then I see cases when an mbox is used for sending new messages (those messages were added to the project much later). I even added a new type of mbox (called unique_subscribers) to the so5extra project as a consequence of such cases. Sometimes we start by using just one MPSC mbox for sending messages to agent X, and after some time we need another agent Y to do something new, but it's convenient for us to keep using the same mbox. Untyped mboxes allow us to easily change one type of mbox to another without rewriting big parts of the project.
Nevertheless, I think this direction is interesting and it may be useful for some situations. And I would be curious to make another attempt to think about typed mboxes. But this requires a real need for such functionality. That's how in the case of the need to subscribe mbox to mbox: you voiced an interest in such a feature, then I encountered a similar need myself. This convinced me that this feature is really needed and will now appear in SO-5.8.0. So if there will be real interest in typed mboxes, I will add such a request into the wish-list.
from sobjectizer.
Thanks @eao197 for your insights. I have no issues in my scenario since I have access to the source code and the agents are pretty small (trying to keep things as simple as possible). I was just wondering what was the state of the art on this in SObjectizer. Your reply is very helpful, thanks a lot.
Making subscriptions among mboxes is definitely something worth for my use cases and typed boxes might be useful I guess, or you can just redirect every message from one mbox to its subscribers. I think both the use cases are worth considering.
In my scenario, I have this generic agent that enables redirecting specific messages from a source to destination. The syntax is more or less:
some_context.add_parrot<MessageA, MessageB, MessageC>(src, dst);
All such "parrots" are added to a single active group (aka: they all share the same thread), however each has its own cooperation in order to be deregistered individually
from sobjectizer.
Related Issues (20)
- Asynchrony of register_coop HOT 4
- Documentation for message_holder_t has to be extended HOT 1
- A usage example for agent_t::limit_then_redirect method in API Reference HOT 1
- Deprecation of coop_t::deregister and coop_t::deregister_normally methods HOT 1
- [idea] An emergency stop of SOEnv on an exception in noexcept context HOT 1
- `so_evt_finish` not called until `so_evt_start` is running? HOT 2
- Should agent_t::so_drop_subscription* methods be marked as noexcept? HOT 1
- Should delivery filters be checked for noexcept-ness?
- bind_and_transform HOT 10
- so_5::details::make_message_instance_impl metafunction doesn't set message mutability flag properly HOT 1
- limit_then_transform for mutable messages HOT 1
- Allow `const auto &` as an argument for delivery filter in single/multi_sink_binding HOT 1
- Should there be agent_t::so_disp_binder() and agent_t::so_coop_default_disp_binder() methods? HOT 2
- [idea] Make so5extra's revocable timers the default implementation for timers in SObjectizer
- Another constructor for wrapped_env_t that waits completion of init-function HOT 1
- Use of message limits and state_t::time_limit
- Optional name for an agent? HOT 2
- New method `as_string_view` for so_5::stats::prefix_t and so_5::stats::suffix_t HOT 1
- SO_5_TYPE shouldn't be used for so_5::stats::messages::quantity
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sobjectizer.