-
Notifications
You must be signed in to change notification settings - Fork 8
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
Improved timers #272
Improved timers #272
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #272 +/- ##
===========================================
+ Coverage 24.22% 57.17% +32.94%
===========================================
Files 70 69 -1
Lines 9539 9548 +9
Branches 1257 1242 -15
===========================================
+ Hits 2311 5459 +3148
+ Misses 7116 3331 -3785
- Partials 112 758 +646 ☔ View full report in Codecov by Sentry. |
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.
The code looks great and I like the changes. Just one minor comment on correcting a function description.
include/margo-timer.h
Outdated
* @brief Cancel a started timer. | ||
* @brief Cancel a started timer. If the timer's callback | ||
* has already been submitted as a ULT, this ULT will | ||
* eventually be executed. Hence, calling margo_timer_cancel |
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 think this function comment is incorrect. There is no wait_pending() function. By my reading of the code it will block until timer ULTs are complete (if they have been launched already). I like that because it is much simpler anyway.
In place of the note about wait_pending() it should probably warn callers that this particular could block (in an Argobots-safe way, that is).
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.
Good catch! I forgot to update this comment.
I added a |
This PR improves the timers API in a few ways:
margo_timer_create_with_pool
to specify the pool in which the timer's callback should be submitted as a ULT. If ABT_POOL_NULL is passed, the callback will be executed in the context of the progress loop. I added a warning in the function's documentation that this should be avoided and has limitations (such as not being allowed to call any margo functions in the callback since they could deadlock).margo_timer_cancel()
. Previously, this function would only remove the timer from the list of future timers, but would not cancel a ULT submitted by the timer. Now it does, and it also waits for completion of any ULT submitted by the timer. This guarantees that aftermargo_timer_cancel()
returns, the timer's callback will not be called, hence any data associated with the callback can safely be freed.margo_timer_destroy()
. Previously, this function would cancel the timer and free its memory. Now it does not cancel the timer. If the timer hasn't started and hasn't submitted its ULT, it is going to free the timer's memory. If it has been started or if it has a pending ULT, it is going to mark the timer for deletion and the last ULT using the timer will destroy it.__margo_timer_init
being used from inside margo andmargo_timer_create
being used from outside. The distinction is now gone, and several of the__margo_timer_*
function have been removed as they were redundant with the public version.