Actor Framework Discussions

Showing results for 
Search instead for 
Did you mean: 

Actor Framework favorite (mis?)use cases



felipe.foz  : You're going to love LV2020. 🙂
Message 31 of 33

@AristosQueue (NI) wrote:


felipe.foz  : You're going to love LV2020. 🙂

Yes, you were right.


Just had time to read the examples and implement the interfaces in one of my projects.

It was incredible the amount of code removed (VIs, Message Classes) with just one interface.


Felipe Pinheiro Silva

Follow my blog for LV content!

0 Kudos
Message 32 of 33

@Taggart wrote:


@drjdpowell wrote:

@AristosQueue (NI) wrote:


Also, proving that there isn't a cycle is a hard thing. Why not start with an infrastructure that pushes back on that ever existing in the first place?


That I can strongly agree with, though I'm using a different infrastructure that uses different methods to discourage cycles.

Since cycles can have an arbitrary number of participants ie A->B-C->D->...->A, the only way to possibly avoid coding them is to know exactly who each participant is observing and keep track of all that. That is a daunting task in a program of any real size. Not to mention that dynamic loading makes it impossible to tell who is observing who at edit time. 


Sorry, I must not have seen this at the time.  There are simple rules that can prevent even complex cycles.  In Messenger Library, one can only "observe" an actor (non-AF "actor") you have the address of, and you only have the addresses of the actors you create.  You can pass addresses around and build something more complicated, but this has to be deliberate and it is a lot of steps to build up a complex cycle.  I think you are thinking of "peer-to-peer" global addressing, where it is easy for any "actor" to communicate with any "actor".   Then, it is easily possible to produce a complex cycle from many seemingly disconnected small connections and not realize the very hard to debug cycle one has created.

0 Kudos
Message 33 of 33