You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The DispatchManagingActor example in the class docs should do something else than just listening to updates.
Maybe it is worth adding some other logic to represent that, maybe implement a ClockActor that ticks every X time, where X is a dispatch option? So we have a select() instead with a timer (printing the time) and the updates_channel.
The example should also clearly show that the managed actor's _run() method should first receive from the updates channel, otherwise it might miss the initial setup of the dispatch. This should also probably be mentioned more explicitly in the docs themselves, not just the example.
I even wonder if we should somehow enforce this, requiring a special start() method for managed actors or something like that.
The
DispatchManagingActor
example in the class docs should do something else than just listening to updates.Maybe it is worth adding some other logic to represent that, maybe implement a
ClockActor
that ticks every X time, where X is a dispatch option? So we have aselect()
instead with atimer
(printing the time) and theupdates_channel
.The example should also clearly show that the managed actor's
_run()
method should first receive from theupdates
channel, otherwise it might miss the initial setup of the dispatch. This should also probably be mentioned more explicitly in the docs themselves, not just the example.I even wonder if we should somehow enforce this, requiring a special
start()
method for managed actors or something like that.Originally posted by @llucax in:
The text was updated successfully, but these errors were encountered: