Embedding actors into a non-actor framework architecture

[WavePacket]

Hi Guys,

I've got a question about reusing an actor in a other, "regular" project (like a QMH or QSM). I've been under the impression that to use an actor it's somewhat required that the whole project be actor framework if it's needed anywhere. I began questioning why is that and started thinking perhaps I was partially wrong. 

I was thinking, what's stopping me from launching my other actor as a root actor in a QMH, storing the actor's enqueuer in a shift register and sending the actor messages? That would seem to be ok, right? Perhaps it's only if I want bi-directional messages that the main program should also be an actor. (Of course, it might be pertinent to ask in the first place why it's ok to not have bi-directional messaging, but there are a couple of projects that I could see a new actor developed that might be nice to use in an older program, where the older program is too burdensome to rewrite altogether.)

Thanks,

-wavepacket

[CaseyM]

I've done what you've thought of and launched an actor in a (previously) non-actor project. It works fine for things like a data or event logger, but as you've pointed out, it becomes an issue if you need to send Msgs back from the actor to the rest of the program. But yeah, going one way (Msgs into the actor) is fine.

[BertMcMahan]

I could envision an actor "adapter" that could call another, regular actor. Basically you'd pre-configure it with a regular queue or event refnum and the actor you want to launch, then launch the adapter actor.

The regular actor you just launched will generally try to send messages to its caller, which if it's launched as root-level then it won't be able to do, so you'd need to rewrite it to handle some alternate communication path. With an adapter launcher, you could let the regular actor send its messages the normal way. The adapter actor would then receive those message objects, unpack the payload, then repackage it into your desired user event or standard queue reference to be sent back to the caller program.

As long as you set up your launcher to run synchronously until the regular actor launches, you can still use the regular actor's enqueuer to send it messages. You'll just receive data back through a different mechanism.

Edit: Instead of giving the adapter a predefined queue reference it could just make it on its own. That launcher would then return both an Actor enqueuer (to send messages to the launched actor) and a queue or user event refnum on which you'd receive data.

[justACS]

This.

Only I'd probably go with passing the conventional queue into the adapter actor before launch, rather than create an additional queue exchange.  The queue you pass in is the queue of the non-AF actor that launches the adapter.

Assuming the adapter actor launches the actual nested actor before it enters message handling, you won't have to worry about timing issues.

We teach something like this in the AF course, btw.

[WavePacket]

---

@justACS wrote:

...The queue you pass in is the queue of the non-AF actor that launches the adapter.

...

---

The non-AF "actor" is per my original post the old code that's too costly to be rewritten?

[Thomas_robertson]

Just wanted to say we've done this a lot and it works as well as could be expected.    Our code base is around 30 years old with tons of Queued state machines, a few Queued Message Handlers, and in the last 5 years more and more actors (which are sort of taking over the architecture bit by bit).   We have global message buses and "LV2 style globals" which the actors interact with.  Bit by bit there are root actors for subsets of our system that eliminate most LV2 global work and instead communicate up to the root actor (e.g. Display subsystem root actor) which in turn handles any messy glue with the older communication protocols.  We also have wrapped a lot of our high level helper loops with actors.  So instead of being loops probing a stop global while doing work, they are handling timed messages (or they are now event driven) and doing whatever global level work they do, except they're a bit more visible through the monitored actor framework and more likely to be killable through the monitored actor window.

But we also have Queued state machines just launching one off actors such as common display entities that are embeded in subpanels.  In this case I like having a "synchronous" class which serves as a frontend for the synchronous (i.e. not parallel, Actor) code.  So through the synchronous class you have an init method that behind the scenes launches the actor, setting up communication queues, holding the Actor Enquer, binding the actor core to a subpanel on the QSM if need be.   Then you continue to interact with the entity through the synchronous class in your QSM code without having to pollute that code with the details of actor communication.

[justACS]

---

@WavePacket wrote:

---

@justACS wrote:

...The queue you pass in is the queue of the non-AF actor that launches the adapter.

...

---

The non-AF "actor" is per my original post the old code that's too costly to be rewritten?

---

Yes.  If I recall correctly, you mentioned the old code is a traditional queue driven message handler, which can be very actor-like.