Jump to content

Conner P.

  • Content Count

  • Joined

  • Last visited

Community Reputation


About Conner P.

  • Rank
    LAVA groupie

LabVIEW Information

  • Version
    LabVIEW 2017
  • Since
  1. Bob, I just saw your document. WOW! Thank you for contributing that to the community. I'm looking foreward to reading it!
  2. Hi all, I have a question mostly directed at James, but others can feel free to chime in. How do you represent your actors in UML diagrams? What I have in mind is that receivable messages correspond to public methods, frames in the state machine refer to private methods, and State/Event updates to the listener registry are private and notated with <<notify>> . What do y'all do?
  3. I PM'd James the following question regarding unit testing and the Messenger Library actors. He asked I repost it here so that he can answer publicly for the benefit of the community and it is documented with the rest of Messenger Library discussion.
  4. Ah yea, I hadn't considered using an object. But since I was planning on passing a cluster, what difference does it make if it is an object or a plain cluster? Not much in the message passing regard. But, packing the data in an object does open the door to created class methods to manipulate the data, which in turn could use the command-pattern for the ThreadPool. With that, it wouldn't be so much passing in a set of parameters and returning a separate result, but more passing the object through the ThreadPool and "pushing a button on it"-- very assembly line like in my mind. I think I just realized the potential of the command pattern.
  5. Hi James, how would you recommend making a message class for a specific data type? As a little preview I am trying to make a thread pool class which includes a manager actor and worker actor clones. Normally I would find the variant solution satisfactory, but as we discussed in my post on the NI forum, I have a high throughput application and don't want to give up speed I don't have to. My initial thought was to just make a subclass of MSG.lvclass like variantMSG.lvclass (sorry if the names aren't 100%, don't have LV with me atm), but then I discovered that the internal send and extract variant message methods DO have "abstract" parent versions within MSG.lvclass. I didn't want to go fussing with the library base classes, so instead I designed the send and extract methods of my customMSG.lvclass to accept a generic MSG object and then internally cast it to my custom child class, allowing the internal methods to do the extracting or writing. Is this a reasonable approach?
  6. Holy crap you weren't kidding! That is one deep rabbit hole. I'm amazed at the internal complexity of this library. I guess you really did earn that Dr. title! Very clever solution with the asnyc call to spin-up the reference checker. Is there any reason for choosing a queue vs some other type of reference?
  7. Hi James, I was looking through the VIs and tried searching for an answer, but I can't seem to get my head around how nested actors get triggered to shutdown when their calling actor shuts down. I saw somewhere mention of a queue references whose sole purpose was to indicate to the nested actor if the calling actor is alive, but I cannot figure out how that is implemented in the code. I understand such info is not necessary for usage of the library, but I am curious. Could you please highlight the implementation of this feature?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.