"Synchronous" export to file from several actors

[drjdpowell · Accepted solution]

---

@BertMcMahan wrote:

---

---

Non-interaction is something of a feature here. If I'm on a particularly slow network connection (like the edge of wifi) the Write operation may take 5 or 6 seconds to send to the network. I'd rather my users not try to change a setting or try to initiate a new test before the Save of the old test is done. The Main FP just serves as a place for some common settings and to hold the "Current Test" subpanel, so there's no other interactions that need to take place (and again, I want to be confident the Save operation is finished before anything else can take place, hence "synchronous" in quotes. It doesn't have to actually use synchronous messages, just block until done).

... 

I do really welcome anyone telling me why I'm wrong though. 

---

I'm tempted to do the opposite and tell you you are right.  Blocking (or disabling the UI temporarily) is an easy-to-understand way to ensure no race-conditions, like "User hits Export and then changes something before the Export competes, thus changing the Export data".   That is a race-condition bug.  One can definitely avoid it through sticking very carefully to AF principles, but it seems to me that it is easy to screw up, and hard to be sure you have excluded any race condition.

[BertMcMahan]

Yeah my gut feeling is that I want synchronous behavior, so even if I don't use synchronous messages I'd need to implement it elsewhere.

I wound up doing a couple things to handle the errors. Like you said, the error should go to the caller actor, not the callee, so I just didn't wire the error output through in Send Message and Wait for Response. Instead, I wired the error to the variant output terminal. That way the error is seen when the message is called and I don't have to do any filtering.

I also found out that, in AF, a timeout error will not just send an error to the caller but to the callee as well. I wound up just filtering this error in Handle Error but I probably should've done it in a Do.vi override for that specific message. Right now it's the only sync message I have to handle so I won't worry about it.

If I were to do it again I'd bundle up the data to an exporter object (maybe actor? probably just regular object) just so I don't have to handle file exports in the test actor itself, which somewhat violates the Single Responsibility Principle. That slightly complicates the "load" side of "save and load" since I have to read the file to know what it is, then select both an actor and a datatype loader object, but it's not too much more complicated than what I have now.

As it is now it does seem to work fine. Looking back I do feel silly for adding a timeout here... a file export isn't something that needs a timeout, just an error.

Thank you all for the advice. It sounds like this might indeed be one of the few "acceptable" cases for a sync message after all.

[Thomas_robertson]

Not OP.  Thanks for the "Scatter-Gather" terminology.   Do you know if anyone has formalized that for actor framework?  Maybe a Scatter-Gather interface(s) that actors can inherit from?

[drjdpowell]

---

@Thomas_robertson wrote:

Not OP.  Thanks for the "Scatter-Gather" terminology.   Do you know if anyone has formalized that for actor framework?  Maybe a Scatter-Gather interface(s) that actors can inherit from?

---

I don't, but looking at "Reply Msg.lvclass", it looks like it would be quite easy to add a Scatter-Gather version of "Send Message And Wait For Response.vi" (basically, just add a For Loop and some "timeout-remaining" calculation).   That would send a message to multiple Actors and return an array of Variants from all the Replies.  That would be a Synchronous (blocking) version of Scatter-Gather; an Async version, where the Caller doesn't block and the Array of Variant Replies comes back as a single Message, would a bit more complicated, as it would require an Async-called subVI to do that actual waitin, but you could model calling that subVI on "Time-Delayed Send Message".