Error 1556 while sending a message to other actor

[mirode]

You are right, Danielle, but I was not aware that it should NOT be placed outside of the actor, apparently.

[FabiolaDelaCueva]

mirode wrote:

You are right, Danielle, but I was not aware that it should NOT be placed outside of the actor, apparently.

User Events references have "tricky lifetimes"

I have used them extensively in other architectures and had to learn the hard way that you want to create the references inside the VI that will be in memory the longest, because as soon as that "creator VI" goes out of memory, the reference goes with it.

Glad you were able to solve your problems and thanks for sharing. We all learn from these posts.

[AristosQueue (NI)]

FabiolaDelaCueva wrote:

User Events references have "tricky lifetimes"

User Events have the same lifetime rule as all other refnums in LabVIEW -- they go stale when the top-level VI that created them goes idle. What gets tricky is when you try to use *any* refnum for communication between two different systems. That's why the AF handles the lifetime management of the enqueuers -- they're always tied to the receiver.

Mirode wrote:

> You are right, Danielle, but I was not aware that it should NOT be placed outside of the actor, apparently.

Ideally, you would never use ANY refnum for communication between actors other than the enqueuer. I have yet to see a use case where introducing another refnum didn't lead directly to problems. Given that, you should always create any refnums used by your actor inside that actor. The sole exception is when you are creating a reference in the caller actor that the caller will give away to the nested actor -- in other words, after it sends it to the nested, the caller won't be touching it again -- and you can guarantee that the caller will have a longer lifetime than the nested actor. Note that in this case, you are STILL not using the refnum for communication between the actors.

I said ideally. I'm willing to entertain the possibility that there might be some use case for having a parallel channel of communication. But every one that has come up thus far on this forum and in my work with other customers has turned out to be a bug of some kind. Use the message queues and nothing but the message queues between actors.

[FabiolaDelaCueva]

AristosQueue wrote:

I said ideally. I'm willing to entertain the possibility that there might be some use case for having a parallel channel of communication. But every one that has come up thus far on this forum and in my work with other customers has turned out to be a bug of some kind. Use the message queues and nothing but the message queues between actors.

Or for others watching this forum who might not be using Actor Framework, we could summarize this as : "if you are doing other type of Actor Oriented Design, just keep your channel of communication to one type." But that is another story and a topic for a Community that is not called "Actor Framework"

Also, thanks for this:

AristosQueue wrote:

FabiolaDelaCueva wrote:

User Events references have "tricky lifetimes"

User Events have the same lifetime rule as all other refnums in LabVIEW -- they go stale when the top-level VI that created them goes idle.

Nice, direct, simple explanation. Unfortunately learned that one the hard way.

[AristosQueue (NI)]

FabiolaDelaCueva wrote:

Nice, direct, simple explanation. Unfortunately learned that one the hard way.

Ah. That would qualify as tricky then!

FabiolaDelaCueva wrote:

we could summarize this as : "if you are doing other type of Actor Oriented Design, just keep your channel of communication to one type."

Exactly.

[dsavir]

AQ, then if I understand correctly, events should be used for communication between the core loop and the event loop of the same actor, correct? Because there is the issue of the Actor data being split by value, so either events need to trigger messages to self or all messages from external actors need to trigger events (or use a DVR in the actor, but I saw many people don't like this option). Then the event is created in the actor that uses it and messages are used between actors and everything works. Yes?

[AristosQueue (NI)]

dsavir wrote:

AQ, then if I understand correctly, events should be used for communication between the core loop and the event loop of the same actor, correct?

Yes. If not events, you might choose queues or notifiers or something else. But whatever you choose, I strongly encourage you to choose only one type of communication if only to keep things clear.

dsavir wrote:

Then the event is created in the actor that uses it and messages are used between actors and everything works. Yes?

Yes.

dsavir wrote:

(or use a DVR in the actor, but I saw many people don't like this option).

Because a DVR is not a method of communication. It is a method of data storage, and using it for communication leads to all the same synchronization problems that are the whole reason we developed the Actor Framework in the first place. 🙂 Most of us would use the DVR only if the value of the DVR was never changed at all after the DVR was created (basically, to share constant values among a set of loops).

[dsavir]

Thank you AQ! And thanks mirode, this thread helped arrange some things in my head

[mirode]

Indeed quite a few interesting things have beeen said. Thanks AQ and All.

BTW, Monitored Actors from Oli's post (https://decibel.ni.com/content/thread/18301?tstart=0) is a brilliant invention, I can only recommend it to whoever is not yet using it (if anyone on this forum).