Open leenozara opened 5 years ago
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()
.
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
.
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:
OnceJob<Msg>
and RepeatJob<Msg>
, internally capture them as a closure and call job.send
in the closure body,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.
In addition to scheduling an actor the timer should support scheduling a function (or future).
cc @ghtyrant