Actor API

[japaric]

Hello @rtic-rs/devs!

We (Ferrous Systems) have a working proof of concept (that needs some cleanup) for this feature but wanted to start a discussion around it with an RFC before throwing a lot of code at you. (actually, the RFC may be longer than the implementation 😅)

@perlindgren there might be some similarities here (minus the nice graphs) with the concurrent reactive objects / components idea we discussed a while ago.

Rendered text

[japaric]

Proof of Concept implementation: rtic-rs/rtic#537

[japaric]

Happy new year @rtic-rs/devs and congratulations on the 1.0 release] 🎉 . Would you now have bandwidth to consider this proposal? Should I rebase the linked PoC PR?

[AfoHT]

In this weeks meeting we added as an action point to study this PoC, not sure if having it buildable is crucial for this first step

[AfoHT]

This functionality seems generally desired: rtic-rs/rtic#428
👍

[mryndzionek]

This is a very interesting RFC. Would there be a chance to also add dynamic/runtime subscription and unsubscription to (many) message types?

[japaric]

@mryndzionek an interesting idea. as this feature is pretty much based on RTIC's tasks and resources model, I think it would be possible to turn subscriptions on and off at runtime (effectively "masking" the dispatch of some software tasks), but you would need to declare upfront all the possible subscription you may enable at runtime (this is required by RTIC's compile-time guarantees). Such feature raises the question of what should happen if you send a message to which no actor is subscribed to -- in the current design that's a compiler error. That could be handled by simply dropping the message or raising an error; either is possible but what should be the behavior is a design question. At any rate, such a feature sounds a possible extension to the core actor feature proposed here.

[mryndzionek]

That could be handled by simply dropping the message or raising an error

@japaric, I think this should be an error. Ignoring a message should be done explicitly. This is how it's done in similar systems (QPC, etc.). The only two things I'm missing right now in RTIC are the 'runtime' subscriptions and hierarchical state machines support. Both features are really useful. Hierarchical state machines can be added by an external crate, like Finny. Runtime subscriptions need however to be implemented directly in RTIC (to not be cumbersome to use, at least).

[japaric]

comment from 'bradleyharden' on matrix -- answering here so the idea doesn't get lost in the matrix backlog

I took a brief look at the RFC just now. It looks interesting. It reminds me of the structure of an app I'm using right now. But there is a wrinkle that wouldn't allow it to be used. I wonder if you have any thoughts.

Essentially, I have a hardware task that is triggered at the completion of DMA transfers. There are periods where the transfers are consumed and periods where they are ignored. When the hardware task is "idle" and ignoring transfers, it checks an SPSC queue with instructions. Those instructions modify what it will do next, including triggering its transition to the "busy" state. While busy, it does not check the SPSC queue at all.

This feels like it is essentially a knock-off version of some type of Actor API. But it interplays with hardware tasks as well

I think that could be modeled as an Actor that takes 2 types of messages. one type is DmaEvent sent by the hardware task. the hardware task only forwards DmaEvents to the actor and only needs read-access to the DMA status register. The actor owns the rest of DMA registers and starts and manages transfers.

the other type of message is StartDmaTransfer(Payload) emitted from other parts of the system. to handle the "idle" periods where no new transfer can be started you'll need the "masking" mechanism mentioned above so you can tell the actor to stop processing messages of the StartDmaTransfer type. while that subscription is masked, messages should continue to be added to the message queue just not processed. when the subscription is unmasked then next queued message will be processed. in this case, the actor itself will be masking one of its subscriptions

[perlindgren]

Trying to digest the discussion. The idea would be to have the set of listeners to be dynamic, which would benefit both clarity (moving some logic to the framework) and efficiency (since the actor would not need to be invoked and later just ignore). Sounds reasonable.

One thought: would make sense to be able to dynamically instantiate new listeners (given that we have some backing allocator like heapless). Useful e.g., if want do implement a server, that can keep a number of connections up. Of course one could pre-allocate the maximum set of listeners, but maybe it would "feel" more natural to allocate/free listeners programatically.
/Per