I've made my own copy of the actor framework to implement some changes that I really needed. Because of this I cannot really share code easily and my framework branch is not automatically updated. The changes that I've made could be made without overwriting the framework if only the framework was more open.
(a bit of what you can do with the changes are listed in brackets)
Creating more functionality for actor framework classes should be done through children of the classes in the framework. The way the framework is setup makes it impossible to add functionality to some classes:
- Message Priority Queue
- Message Enqueuer
- Message Dequeuer
- Message Queue
These classes are all obtained with a class constant internally in the framework.
I would really like it if we could have a class input to all these so we can implent additional queue functionality and have this input as part of either an actor dynamic method inside of the Actor.vi that the constants are read from or an input to the launch VIs.
[Magic can be done with enqueue in front combined with batch message children and public scoped read self enqueuer --> self propagating message array]
Changing functionality through dynamic dispatch is the way it's meant to be done. But most of the Actor framework VIs are static dispatch. Vi's that I'd like to make dynamic are:
- Launch Actor Core.vi (and probably all the other launchers as well)
- Actor.vi
- Send Message and Wait For Response
- Send Batch (Or change the class constant to a control
[adding a counter to an actor child would be easy with a dynamic dispatch of Launch Actor Core]
Heavy use of access scopes makes some actions impossible (as intended). I'd like to have the following changed to community scope and added as friends to the Message class:
- Read Self Enqueuer
- Read Caller Enqueuer
[Messages that flush the queue, view the queue status enqueues them self on the queue and so on can be made]
And lastly but surely the most controversial is the change of pre launch init from non-reentrant to reentrant.
Yes by doing this and launching an actor from within the vi will crash your program. But doing it as is will result in a deadlock anyway. The protection of making it non-reentrant is extremly weak! I'd rather have some warnings. What you gain is that the actor that you are launching and the nested actors that it will launch from the pre launch init can share their private data during launch! This is extremely useful with actor shared notifiers, DVRs and so on. Note that you can do this halfway by launching from the actor core.vi however the data will only be shared up in the hierarchy not throughout the entire hierarchy... which is bad/sad.
I hope you'll look into at least some of this to enable a more dynamic usage of the framework for advanced users.
