How to create reply message on request

[drjdpowell]

Just to needle the AF developers, but the problem WavePacket is describing, have subactor A execute an action then have actor B do something, is very common and should be very easy.  If it is not easy, that suggests the AF is missing something.

[cbutcher]

One option that might work for you and avoid synchronous messaging (sort of) is to fall back on a solution similar to what you previously mentioned.

You could have the first actor, A, receive the new settings and set them, then send a message instructing B to carry out a measurement.

B then makes the measurement, and sends two messages, one directly to caller A (is A B's caller?) saying it finished, and one to whoever wants the result (possibly via A, in the first message).

If you use the reply message setup from A to B, then you don't need to store state, but you've locked A whilst B makes the measurement.

On the other hand, you can have A move into an internal "making measurement" state (you might have called this "test"?) and pass any messages with new settings+measurements into a separate internal queue to handle when it is free (i.e. it receives information from B that B is available again).

James, I'd be curious to know how you'd do this instead with Messenger Library. I expect the same pattern could probably be copied in AF (although I'm not so strongly attached to AF that I wouldn't be still tempted in this case to make B above into a non actor and having only a synchronous behaviour via e.g. a wrapper for DAQmx or similar).

[WavePacket]

Well, we're certainly diving deep. Thanks for the detailed feedback. 

My idea more fully spelled out is that A & B are nested hardware actors that are constantly communicating with a root/ GUI actor. A & B are constantly streaming data up to the user and displayed by the root/ GUI actor.

The sync bit is this, the user may select to do a long test which my current idea was to build around synchronous reply messages. This would lock the GUI, probably not desirable -- I should think how to figure this issue out. 

The async bit is this, the second requirement is for the program to have a manual mode where the user might be trying different settings, taking measurements etc all while having the latest data being updated. This requirement is why I want AF.

So there is both sync and async bits in the same program, which is why I wanted to try AF out but use synchronous reply messages a bunch at certain points. 

[justACS]

---

@WavePacket wrote:

Well, we're certainly diving deep. Thanks for the detailed feedback. 

My idea more fully spelled out is that A & B are nested hardware actors that are constantly communicating with a root/ GUI actor. A & B are constantly streaming data up to the user and displayed by the root/ GUI actor.

---

Can you clarify something for me?  From the above description, A and B each manage hardware, and are nested actors of Root.  But from reading the thread, it sounds like you want A to change a setting on B, then B takes a measurement and reports the result to A.  Why is A changing a setting on B?

I'm starting to suspect that your issue is actually one of separation of responsibilities.

[WavePacket]

---

@justACS wrote:

---

@WavePacket wrote:

Well, we're certainly diving deep. Thanks for the detailed feedback. 

My idea more fully spelled out is that A & B are nested hardware actors that are constantly communicating with a root/ GUI actor. A & B are constantly streaming data up to the user and displayed by the root/ GUI actor.

---

Can you clarify something for me?  From the above description, A and B each manage hardware, and are nested actors of Root.  But from reading the thread, it sounds like you want A to change a setting on B, then B takes a measurement and reports the result to A.  Why is A changing a setting on B?

I'm starting to suspect that your issue is actually one of separation of responsibilities.

---

Sure, let me clarify. A and B each manage separate hardwares, and are nested actors of Root. Actor A needs to change a setting on the hardware it manages, and then I need to have B report a measurement from a separate hardware that B manages. As an example A turns on a lightbulb, and then B uses a photodiode to measure its brightness.

So I was thinking of using two separate synchronous reply messages:

1. Root sends a synchronous reply A telling it to turn on the light bulb, and waits for A to reply that light bulb is on

2. Then after receiving reply from A, I send a separate synchronous reply message message to B a which requests a photodiode measurement. 

Is that the easiest way to have this program which has requirements both synchronous (described in this post) and asynchronous (described in an earlier post)?

[justACS]

---

@WavePacket wrote:

---

---

Sure, let me clarify. A and B each manage separate hardwares, and are nested actors of Root. Actor A needs to change a setting on the hardware it manages, and then I need to have B report a measurement from a separate hardware that B manages. As an example A turns on a lightbulb, and then B uses a photodiode to measure its brightness.

So I was thinking of using two separate synchronous reply messages:

1. Root sends a synchronous reply A telling it to turn on the light bulb, and waits for A to reply that light bulb is on

2. Then after receiving reply from A, I send a separate synchronous reply message message to B a which requests a photodiode measurement. 

---

Reply messages are not required for this scenario.  A and B are free to do their own things.  A gets a message to toggle a bulb, and sends a normal message to caller when that is done.  B gets a message to take a measurement, and sends a normal message when that is done.

When Root is trying to take a measurement, it knows to ask A to turn on.  When it gets a message from A that the bulb is on, it requests data from B.

The key is to put Root in a mode where it knows it is taking a measurement, so requesting some data is just part of its response to getting a message that the bulb is on.  Actors can (and should) change how they respond to their next message; it is one of only three things actors do (with respect to each other).

When you don't want to take that measurement, put Root in an idle mode.  The Bulb On message doesn't trigger a request for data from B.

I use state pattern actors a lot for this sort of behavior.

[WavePacket]

---

@justACS wrote:

---

@WavePacket wrote:

---

---

Sure, let me clarify. ... 

---

...

I use state pattern actors a lot for this sort of behavior.

---

So I probably have some learning to do here. BTW, I'm understanding your above post to mean that synchronous reply messages are not required, but that asynchronous reply messages are used. Feel free to correct me there.

My concern (potentially just from ignorance) is how well state pattern actors scale. I've had to create tests with hundreds of synchronous steps. I can envision hundreds of synchronous reply messages following each other, but how to envision hundreds of states in a state actor?

[WavePacket]

Is this trick (link) an answer to my need?

[WavePacket]

---

@WavePacket wrote:

Is this trick (link) an answer to my need?

---

Edit to add that no, that just guarantees the messages are sent in a certain order - not that the actions are done in certain order.

[justACS]

---

@WavePacket wrote:

---

My concern (potentially just from ignorance) is how well state pattern actors scale. I've had to create tests with hundreds of synchronous steps. I can envision hundreds of synchronous reply messages following each other, but how to envision hundreds of states in a state actor?

---

I can't say if it scales, myself.  I've built a sequencer based on state pattern actors, but we have only about ten step types.  It should scale for performance, but maintenance might get rough.

I'd need to study some of your specific interactions to make a recommendation.