Leaderboard

It's real. It's very real. Long story short, the need to have this Max optimized reared it's ugly head for some development happening in the ivory tower and this is the lovely precipitate. This will greatly help the speed future versions of the AQ Lineator deserialization process. So although I don't have the specific data on it, yes, this should be crazy faster. ~,~

I think your speed test is a little flawed. You shouldn't be updating any UI indicators in states that you want to know how long it takes to execute, because these operations like updating the UI happen asynchronously and can effect the time a state takes to execute in an unpredictable way. I would also recommend removing debugging, and automatic error handling. That being said I still saw a large improvement using the example class you had. I don't have any other classes to test it with at the moment.

I have started compositing my classes. You could include a "Protection" class in your different file formats which offloads the protection functionality into a seperate class. That was inheritance is no longer an issue. You then have a file class with a bunch of sub-classes which you can access one by one and query whether they're implemented or not.

I don't think it takes too long after deciding to do an actor based project to run into the case where you have an actor spun off without a way to kill it. You'll figure that out and get your solution working so you can pass it off to someone else and forget about it. Soon after, that someone else will come to you and say something like "yeah, those actors are cool and all, but they're really hard to debug" I ran into some of these problems a while ago, so I decided to write a little tool to help with it. I decided to call it a monitored actor. Here were my design criteria: I want a visual representation of when a monitored actor is spun up, and when it is shut down. From the visual representation, I want to be able to: stop actor, open their actor cores, and see if they're answering messages The visual representation should give you an idea of nested actor relationships. Implementing a monitored actor should be identical to implementing a regular actor. (meaning no must overrides or special knowledge) Monitored actors behave identically to Actors in the runtime environment. It turns out that you can pretty much accomplish this by creating a child actor class, which I've called Monitored Actor. A monitored actor's Pre-launch Init will try to make sure that the actor monitor window is made aware of the spawned actor, and Stop core will notify it that the actor is now dead. The actor monitor window contains ways to message the actors and pop up their cores and such. I think it's fairly obvious what each button does except pinging. Pinging will send a message to the actor and time how long it takes to get a response. This can be used to see if your actor is locked up. The time it takes to respond will be shown in the ping status column. if you want to periodically ping all the actors, set the "poll Frequency" to something greater than 10ms. This will spawn a process that just sends ping messages every X ms. Where I didn't quite meet my criteria: If you were to spawn a new actor and Immediately (in pre-launch init) spam it with High priority messages, the Actor monitor window will not know about the spawned actor until it's worked through all the High priority messages that got their first. You probably shouldn't be doing this anyways, so don't. Download it. Drop the LVLIB into your project. Change your actor's inheritance hierarchy to inherit from monitored actor instead of actor. You shouldn't have to change any of your actor's code. The monitored window will pop up when an actor is launched, and kill it's self when all actors are dead. Final note: This was something I put together for my teams use. It's been working well and fairly bug free for the past few months. It wasn't something I planned on widely distributing. A co-worker went to NI week though and he said that in every presentation where actors were mentioned, someone brought up something about they being hard to debug or hard to get into the actual running actor core instance. So I decided to post this tool here to get some feedback. Maybe find some bugs, and get a nice tool to help spread the actor gospel. Let me know what you think. Monitored Actor.zip

Problem Solved. Paul, you were right, the solution resulted from calling NI. Luckily my company has the support subscription. The tech support guy I reached at NI talked me through it. The solution was two fold. (I'd tried both solutions on my own, but not at the same time) First, it's important for all of the VIs to be within the same application instance for the Single-Process variables to work AND it does not seem to be possible to prevent the Web Services VIs from existing inside their own application instance.... Thus Network-Published shared variables are required. Second, in Build Specification, I needed the "Deploy shared variables at application execution" check box. Apparently things work intermittently (rather than not at all) when I neglected properly deploy the shared variables. I've built a small example Installer which deploys the VIs and the Webservices VIs and the Network Shared variables all work. I'm now incorporating the changes into my real system. Thanks for the response. Hopefully if someone else stumbles on this issue, they will also stumble on this discussion. Martin