? Bug in synchro message ?

[AristosQueue (NI)]

---

@drjdpowell wrote:

I've said this before, but it seems a mistake to have a "Reply Message" that is synchronous in the AF without a similarly easy-to-use Async "Reply Message" available somehow.  People will be guided towards using blocking wait on reply in cases where the information should be coming back asynchronously.  

---

How would that be different from any normal message that an actor sends in response to receiving a message? Caller sends "do this thing". Nested receives the message, does the thing, and sends back "thing is done." What specialness is needed?

[AristosQueue (NI)]

---

@AristosQueue (NI) wrote:
How would that be different from any normal message ...?

---

I had a thought... are you talking about a routed reply where the original message specifies who to reply to? I can see that being useful, though it's a pretty specialized use case -- it does come up, but not a lot, when nesteds make requests of callers for resources or specific information. In those cases, it's generally just as easy to just put the return enqueuer in the private data of the new message rather than create a common parent message class. There's a small bit of boiler plate code that could be saved. I haven't seen it as a priority.

But I could have misread its frequency of desirability. Anyone else have thoughts on this?

[drjdpowell]

---

@AristosQueue (NI) wrote:

---

@AristosQueue (NI) wrote:
How would that be different from any normal message ...?

---

I had a thought... are you talking about a routed reply where the original message specifies who to reply to? I can see that being useful, though it's a pretty specialized use case -- it does come up, but not a lot, when nesteds make requests of callers for resources or specific information. 

---

It's more than just where to send the reply.  I true "reply" is tied to the original request.  For example, if I received this email from you, in reply to an earlier email from me:

To: drjdpowell@...

Subject: Re: I need to book a hotel for the CLA summit, where is it?

Body: Madrid 

you will note that two of those three bits of this reply's information were supplied by me in my original request: the address to reply to, and the "reply command" "I need to book a hotel...".   I true Request-Reply is sort of a "thread of action" that is controlled by the Requestor.  A closely related concept is a Continuation.  The request message should contain the continuation somehow.   An AF implementation would see the Request message contain both the address to reply to and the concrete reply message.  

Note that if I had received the message "CLA summit city, Madrid", that doesn't tell me what I'm was needing the info for.   I'm a human, so I can probably remember, but my actors are much simpler creatures and need the message to tell them what to do.  

[Ironman_]

---

AristosQueue ha scritto:

---

---

How would that be different from any normal message that an actor sends in response to receiving a message? Caller sends "do this thing". Nested receives the message, does the thing, and sends back "thing is done." What specialness is needed?

---

If my caller-actor-with-UI has nothing to do except wait the reply (from instrument for example), should I use synch or asynch?

mmm I need more practice with asych organization... in fact with async reply, my UI would be responsive (and not locked). If I need to "block UI action" I could just disable some controls before "send msg", and re-enable them when reply comes (into my instance method -> I have UI-refs or user events to them)

[drjdpowell]

---

wrote:
mmm I need more practice with asych organization... in fact with async reply, my UI would be responsive (and not locked). If I need to "block UI action" I could just disable some controls before "send msg", and re-enable them when reply comes (into my instance method -> I have UI-refs or user events to them)

---

The AF design principles, as I understand them, heavily favour Async over blocking waits, so It is a problem if someone coming to the AF discovers the Synchronous Reply Message first, which one easily does by studying the VIs in the pallets. 

---

If my caller-actor-with-UI has nothing to do except wait the reply (from instrument for example), should I use synch or asynch?

---

A better question is "Should your actor NOT do anything until it has received the reply."  If so use Sync.  Request-Reply is part of a single action: you start the action, make the Request, get the Reply, and finish the action.  Is your actor able to handle any other possible message while it is in this mid-action indeterminate state?   If "yes" then an Async Request-Reply pattern is good.  If "no", then you need to avoid handling other messages and Sync gives you that**.  
 

**Side Note to AQ: there are other possibilities for protecting such "mid-action states"; Erlang uses "selective receive" in its message queues instead of a synchronous query (which Akka uses).  Selective receibve lets one put a hold on some types of messages while still asynchronously processing others.