-
Notifications
You must be signed in to change notification settings - Fork 26
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
task runners as actors #167
Conversation
remove old implementation and start scheduling task runners as if they were normal actors, preventing WS of task runners. this implementation uses a counter of remaining tasks. whenever a task is added to the global task runner messageq, increase the count and wake up and task runner. task runners are awaken as needed, otherwise they are unscheduled.
clean up of tasks. add function for getting the runtime type of tasks
|
||
// if there are message to process, schedule task runner | ||
uint32_t counter = __pony_atomic_load_n(&remaining_tasks, PONY_ATOMIC_RELAXED, uint32_t); | ||
if(counter>0 && is_unscheduled((pony_actor_t*) this_encore_task)){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One reason of treating task-runner as an actor is to get rid of polling, but isn't if
block here polling?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the line 341 polling?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I don't think so. However, on line 332, it's checking if task-runner needs to be scheduled. If actors are changes to using polling, it would be push(sched, actor) if actor_has_msg
. Conversely, in the current implementation which does not use polling, actors are scheduled after they receive messages. If one actor hasn't received any message, there's no overhead at all in the schedule loop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point, and I'll figure out a way of keeping the task runners as close as possible to actors. However, there's a difference with actors and, currently, I do not use the messageq of the task runners since they pick up things from a mpmcq. In the not so distant future, I'd like to implement a strategy similar to lazy scheduling for tasks (http://dblp.uni-trier.de/rec/bibtex/journals/toplas/TzannesCVB14), since I believe it makes sense. There'll be discussion about this, but I believe the idea solves a couple of problems altogether.
remove old implementation that alternate between a task runner and an actor. Schedule task runners as if they were normal actors, preventing WS of task runners.