drjdpowell

Some overheads on common messaging patterns I use from a talk I gave recently: Synchronous Request/Reply Asynchronous Request/Reply Subscribe for future Notifications Asynchronous Dialog Asynchronous Multiple-Actor Request/Reply (aka Scatter-Gather)

A link to the conversation on why the AF uses the pool-of-clones ref in the way it does. Don’t change things until you know what “root loop synchronization†means. I use the same method in non-AF code and haven’t had any issues, so there must be something else involved in the library-locking problem.

The problem is when I recursively dive into sub clusters and convert them into arrays of variants (inside individual elements of the outer array). For example, if I am setting a cluster that matches the JSON text, {subcluster1:{a:1,b:2},subcluster2:{c:3,d:4}} then I will end up with an array of two Variants, each of which is an array of two Variants.

Question: can Xnodes be recursive? If the cluster has a sub cluster, and the corresponding variant in the array contains, not a cluster, but another array, can the Xnode recursively call itself?

No. My first test cluster had five elements, and then I went up without thinking.

I've made a recent entry on the Idea Exchange about this. Here’s the VI I’m experimenting with, referred to in that link: Array of Variants to Cluster of Variants.vi It converts arrays (up to size 50) into clusters of variants, which can be then converted to clusters.

Not really "odd"; that's exactly the stated and desired behaviour. The event locks the panel until it is handled. If you don't handle it, then it remains locked.

Does that not work!?!

Steen’s understanding of how multiple Event structures act with a branched Event Registration matches mine. Not the most useful of behaviors, but you could use it in a “worker pool†system as long as you layer in a way of preventing duplicate handling (like passing a single-element queue in the User Event so only one process can actually get the data).

This package is now on the Tools Network, which required the following changes: — Rename to “SQLite Library†(can’t use “LabVIEW†in name) — move pallet to be under “Connectivity†rather than “drjdpowell†(and the sub pallet icons now look nicer)

“sub-level†VIs? You’re going to have confusion regards, as “top level†can refer to more than one dependance hierarchy. Something started by an ACBR node is “top level†in one sense but not in another.

Greg could build the compound JSON LVOOP object programmatically using other methods in the JSON LabVIEW package, rather than build a cluster and call the “Set Variant†VI that requires most of the data copying.

As I understand it, LVOOP objects are extensions of by-val clusters, not refnums. There is no create nor destroy action and no meaning to “Not and Objectâ€; there is always a valid object. If the objects class contains a refnum of something as an element (a Queue, say), then that will be uncreated by default, and you can write a class method that tests that refnum, but that is not the same as “Not an Objectâ€.

You could solve this with custom Open and Close VIs that maintain a single TDMS reference, and a running count of the number of processes that have called “Openâ€. Count up for Open and down for Closed, closing the file when the count gets to zero. One could also use a named single-element queue to hold the file, as named queues have similar “count-the-number-of-opens†properties.

Here's an improved example. The server is now a single VI, while the client registers two command-pattern envelopes, one for published "data" and one for the servers "shutdown" notification. Each command requires one class with one method. Command Pattern Uncoupling Example2.zip

I’m not familiar with by-ref GOOP, but I imagine GOOP objects wrap a reference of some kind (DVR?). So you are right, one needs to consider stale refnums. However, there’s a difference between something that might be called “null†versus something that is “invalid". An “abstract†parent object might indicate a no-op, while a destroyed object might indicate an error condition. I forget what the OP was requesting.

That's annoying. I understand the reasoning of not letting the called code know access the subpanel ref... because I want the opposite; I don't want the calling code to access the VI ref. I have "actors" for which the actual VI that defines their UI should be private to the actor. I send "Insert yourself in this subpanel messages" and I need a way to get myself out of any previous subpanel I've been insert in. Thanks, -- James

Is it possible to remove a VI from a subpanel without the subpanel reference (just using the VI's reference)?

I just tried making a strict reference constant a type def, and I could easily update it in multiple locations from the type def.

Uh, my demo is command pattern over TCP. I needed to create two new classes and four simple VIs, and if you are willing to use standard Variant/Object messages for data then you only need one class and two VIs. One of those VIs (configuring the command with any meta info) is optional, so that leaves a single Command.lvclass:Do.vi as the only required. Surely this is simpler than any abstraction design, no?

Didn't like my "envelope" demo, eh? Personally I would drop the command pattern for the data message (using standard Variant or Object messages instead) and just use command pattern for actual commands. Then there is one class per message transfer, with server decoupled from client.

You can also create a constant from a strict reference to the VI, then just delete the reference.

Yes, I encountered the same problem with User Events. I now use a watchdog Queue separate from communication. No one ever posts data to this Queue; the watchdog just waits on it to be destroyed. When it does, it posts a shutdown message on the communication Queue/UserEvent (which is always created/owned by the receiving subactor). The watchdog does have to do polling, not on this watchdog Queue, but rather on the communication reference itself, as the watchdog must also abort itself if the subactor shuts down. An advantage of a watchdog Queue separate from communication is that the subactor can continue to receive messages from subsubactors that it has created, should it need to as part of its shutdown procedure.

If your actors are dynamically called, you can use a Queue or other reference created in the top-level. When the top-level goes idle it destroys the reference and this can be used to trigger an error in the watchdog. I stopped bothering to write shutdown code for most subactors a while ago and happily hit the top-level abort button if needed.

Note: I was on vacation when this conversation was going on, and I haven’t read it in great detail. I only use Command-Pattern messages in limited cases, favouring a variation on string-variant messages mostly. But the framework I use can do Command Pattern, and can decouple the command from the “serverâ€. So I made a test example. In it, the Client sends a request (non-command-pattern for simplicity) for a data message (DataAA.lvclass). As part of its reply “addressâ€, it specifies an “envelope message†(CommandAA.lvclass) that it wishes to receive the data message inside of. The TCP Framework keeps the reply address in flattened form while on the server side, so the server never needs to load class CommandAA. The “Do.vi†method of CommandAA.lvclass invokes the “Read.vi†static method of DataAA.lvclass. The methods one needs to write are Write and Read for the Data message, and Do for the Command (with an optional method to add metadata to the Command if desired). [aside: AQ proposed a slightly different form, where the Command class is a child of the Data Message Class; he would need an additional method to support building the Command from the Data message.] Command Pattern Uncoupling.zip drjdpowell_lib_messenging-1.2.1.29.vip drjdpowell_lib_cyclic_table_probes-1.1.0.8.vip