posix: timer: use async pthread cancellation #67871
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The sigevent struct and sigval union members were previously not ordered in a way that produces optimal alignment / reduces padding on 64-bit systems. Reorder members so that pointers come first. Signed-off-by: Christopher Friedt <[email protected]>
There is no requirement that says e.g. CLOCK_REALTIME cannot be used for timer_create(). In fact, the spec explicitly requires it. It might not be ideal, but users should still be able to use it. Signed-off-by: Christopher Friedt <[email protected]>
cfriedt
force-pushed
the
fix-timer-overrun-issue
branch
2 times, most recently
from
df02a9b to
701e7db
Compare
Previously, Zephyr's POSIX API did not differentiate between deferred and asynchronous pthread cancellation. In fact all pthread cancellation was asynchronous. According to the spec, all pthreads should be created with deferred cancellation by default. Note: PTHREAD_CANCEL_ASYNCHRONOUS means cancel asynchronously with respect to cancellation points (but synchronously with respect to the thread that callse pthread_cancel(), which is perhaps unintuitive). The POSIX timer relied on this non-standard convention. Oddly, this change prevents what would have otherwise been a regression that would have been caused by fixing pthread behaviour (in a separate commit). We are effectively uncovering bugs which were probably always present in the pthread.c and timer.c implementations going back quite a few years. Signed-off-by: Christopher Friedt <[email protected]>
cfriedt
force-pushed
the
fix-timer-overrun-issue
branch
from
701e7db to
a490081
Compare
cfriedt
changed the title
Ensure that the realtime clock may also be used with timer_create(). Signed-off-by: Christopher Friedt <[email protected]>
jukkar
reviewed
Jan 20, 2024
jukkar
approved these changes
Jan 20, 2024
|
This is blocking #67223 |
ycsin
approved these changes
Jan 22, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, Zephyr's POSIX API did not differentiate between deferred and asynchronous pthread cancellation. In fact all pthread cancellation was asynchronous. According to the spec, all pthreads should be created with deferred cancellation by default.
Note
PTHREAD_CANCEL_ASYNCHRONOUSmeans cancel asynchronously with respect to cancellation points (synchronously with respect topthread_cancel(), which is perhaps unintuitive)The POSIX timer relied on this non-standard convention.
Oddly, this change prevents what would have otherwise been a regression that would have been caused by fixing pthread behaviour (in #67223).
We are effectively uncovering bugs which were probably always present in the pthread.c and timer.c implementations going back quite a few years.
Fixes #67870
Fixes #67874
Additionally:
CLOCK_MONOTONICstruct sigeventandunion sigvalalignment / padding