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

task runners as actors #167

Merged
merged 2 commits into from
May 18, 2015
Merged

Conversation

kikofernandez
Copy link
Contributor

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.

Kiko Fernandez Reyes added 2 commits May 15, 2015 14:55
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
supercooldave pushed a commit that referenced this pull request May 18, 2015
@supercooldave supercooldave merged commit 05b4201 into parapluu:master May 18, 2015
@supercooldave supercooldave deleted the fix/task-runner branch May 18, 2015 12:11

// 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)){
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants