-
Notifications
You must be signed in to change notification settings - Fork 4
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
watched_tasks: maintain a list of spawned async tasks and propagate errors #47
Conversation
The failed |
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.
Nice! I like the changes and implementation. I thought whether or not the async runtime provides mechanisms to query running tasks and see if anything failed like tokio-console
, but this might be messy (or not even possible). Anyway, there are some minor things that should be corrected but apart from that LGTM.
While addressing your comments I have also changed the way Lines 29 to 54 in 69d52f7
This does however mean that you have to re-review that part. |
The failed |
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.
This looks good to me now and will definitely improve the error handling story in the code base. Feel free to merge.
Adding a custom wrapper around standard APIs seems very invasive to me. Is this really such an unusual problem that there is no idiomatic way? |
Hi @jluebbe
Not in I quite like the tailor-made solution implemented in this PR and think 206 not-that-dense lines of code are an acceptable complexity compared to adding a new dependency to handle this for us. I would prefer merging this as-is rather than adding a new dependency. |
3114a63
to
ea5cc2b
Compare
I've rebased this PR on top of recent |
f66b1b4
to
0612c98
Compare
The WatchedTasksBuilder makes sure that the program ends if any of the tasks fails and also handles error propagation from the tasks to the main() function. Signed-off-by: Leonard Göhrs <[email protected]>
Execution should stop if any of the important threads ends, not just one of the tasks. Signed-off-by: Leonard Göhrs <[email protected]>
The large re-indentation would have made the commit that adds the wtb.spawn_thread() call rather unreadable, as it mixes formatting and code changes. Instead add this commit that _only_ changes formatting. Signed-off-by: Leonard Göhrs <[email protected]>
The large re-indentation would have made the commit that adds the wtb.spawn_thread() call rather unreadable, as it mixes formatting and code changes. Instead add this commit that _only_ changes formatting. Signed-off-by: Leonard Göhrs <[email protected]>
Signed-off-by: Leonard Göhrs <[email protected]>
While .expect() still means panicking it is considerd a better kind of panicking than .unwrap(). Signed-off-by: Leonard Göhrs <[email protected]>
This allows us to display an error message if the server setup fails. Signed-off-by: Leonard Göhrs <[email protected]>
Many small functions is a nice thing in general, but a three line function that is only used once seems a bit over the top. Signed-off-by: Leonard Göhrs <[email protected]>
I've added a comment … Lines 11 to 29 in 6c7a2cd
… that talks about why we went with our own task spawning wrapper instead of using something off-the-shelf. |
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.
@hnez The comment summarizes the discussion very well. You have my approval - feel free to merge.
This PR is based on an idea from a discussion in PR #43, where it was noticed that errors from tasks and threads propagate nowhere.
This PR fixed that by assembling a list of threads and tasks that should not complete before the end of the program and propagating all errors from these threads and tasks to
main()
and beyond.This touches a lot of places, as we spawn quite a lot of async_std tasks (the
tacd
logs now say "Spawned 58 tasks tasks and 5 threads").This PR allows us to add better error handling for tasks and threads (we can for example use the
?
operator to propagate errors out and do not have to resort to.unwrap()
to at least crash thetacd
from within a task on error). Adding this better error handling is out of scope for this PR, as it is already large enough.