riker icon indicating copy to clipboard operation
riker copied to clipboard

Timer to support scheduling a function

Open leenozara opened this issue 7 years ago • 3 comments

In addition to scheduling an actor the timer should support scheduling a function (or future).

cc @ghtyrant

leenozara avatar Feb 07 '19 03:02 leenozara

To clear things up, this is what I wanted to do:

(...)
let selection = sys.select("/user/*").unwrap();
sys.schedule(Duration::from_millis(100);,
            Duration::from_millis(100);,
            selection,
            None,
            "a scheduled msg".into());
(...)

Instead of an ActorRef, I want to be able to pass schedule() a selection, expecting every actor in that selection to be messaged regularly.

In my opinion (note: as a beginner to Riker and actor systems in general), an ActorRef and a selection should be usable interchangeably, as it is the case for tell() et al.

The workaround, as you mentioned in Gitter, is creating an additional actor which receives scheduled messages and forwards these messages to a selection using tell().

ghtyrant avatar Feb 07 '19 23:02 ghtyrant

Understood, thanks for the input. I was thinking along the lines of a schedule function that takes impl FnOnce to be scheduled, meaning a closure or function. That would allow flexibility to do the select you need plus any other scheduled work. I do like your idea however of using the existing schedule set of functions to take impl Tell instead of concrete type ActorRef.

leenozara avatar Feb 08 '19 06:02 leenozara

The timer currently holds a vector of OnceJob<Msg> and RepeatJob<Msg>. We could refactor the scheduler to hold vector of FnOnce and FnMut, that is a struct holding their boxed version and time information. This way:

  • the user could schedule arbitrary function calls,
  • the interface could stay the same, to schedule OnceJob<Msg> and RepeatJob<Msg>, internally capture them as a closure and call job.send in the closure body,
  • as the signature of the scheduled job would be Fn<()>, this essentialy type erases the need to know the Msg type in advance, and it would open Riker toward multiple message types.

The downside would be that the Box<dyn FnBox()> implies one virutal function call, and one pair of heap allocation/deallocation.

riemass avatar Feb 12 '19 07:02 riemass