This repository has been archived by the owner on Mar 5, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 2
Repeating tasks never exit #3
Labels
Comments
Oh you're right-- good catch. |
Who's gonna take care of this? |
Note that it is not a "must-fix" for the competition. |
That's what I was going to say too. The dangling yielding threads won't accumulate enough over the powered on time of the roborio to do anything. |
They don't; but it might cause a problem during extended testing runs.
Maybe not, but might as well fix it; it doesn't seem particularly hard.
Thanks,
Benjamin
…On Thu, Feb 2, 2017 at 3:04 PM, Shreyas ***@***.***> wrote:
That's what I was going to say too. The dangling yielding threads won't
accumulate enough over the powered on time of the roborio to do anything.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIWX5a9AoiLY1nyyaqbzfUhSNF6GWk6rks5rYmDigaJpZM4L0f09>
.
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
There is currently no task cancellation policy. For example, RepeatingTask.run method should return when the robot is disabled and/or switches out of the current mode (autonomous/teleop). Currently it never returns (has a while(true)). The iterator logic thread (collection thread) will never exit - will just be stuck waiting for a yield that never returns. It's not clean and it will leak threads each time there is a mode switch (when a new taskRunner instance is created, leaving the old one still hanging around stuck in some Task's yield call.) Suggestion: cancel task, and yield code should throw an exception. This support may already be there in the underlying Generator framework -need to investigate.
The text was updated successfully, but these errors were encountered: