Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timer to support scheduling a function #39

leenozara opened this issue Feb 7, 2019 · 3 comments


Copy link

commented Feb 7, 2019

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

cc @ghtyrant


This comment has been minimized.

Copy link

commented Feb 7, 2019

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

let selection ="/user/*").unwrap();
            "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().


This comment has been minimized.

Copy link
Contributor Author

commented Feb 8, 2019

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.


This comment has been minimized.

Copy link

commented Feb 12, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.