Anonymous | Login | 2025-01-22 18:46 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0001485 | [Issue 8 drafts] System Interfaces | Editorial | Enhancement Request | 2021-06-12 14:08 | 2024-06-11 09:12 | ||
Reporter | mikecrowe | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | Product Version | Draft 2 | ||||
Name | Mike Crowe | ||||||
Organization | |||||||
User Reference | |||||||
Section | pthread_cond_clockwait | ||||||
Page Number | 1563 | ||||||
Line Number | 51671-51684 | ||||||
Final Accepted Text | See Note: 0005385 | ||||||
Summary | 0001485: It may be clearer to describe pthread_cond_timedwait in terms of pthread_cond_clockwait rather than the other way round | ||||||
Description |
When I wrote my proposed text for issue 1216, I described the new pthread_*_clock* functions in terms of their existing _timed* equivalents. During the drafting of issue 8, various further document changes were made that made the pthread_*_clock* functions the primary ones referenced from elsewhere. I agree with this change. However, the actual description of the behaviour of pthread_cond_clockwait is still written in terms of pthread_cond_timedwait. I think it would be clearer to reverse this too. It's easier to explain the clock as a parameter to pthread_cond_clockwait and then go on to explain that the parameter is not present and where the clock comes from for pthread_cond_timedwait. |
||||||
Desired Action |
Perhaps the affected lines could be replaced with something like: Replace sentences starting at line 51671 with: The pthread_clock_clockwait() function shall be equivalent to pthread_cond_wait(), except that an error is returned i the absolute time specified by abstime as measured against the clock indicated clock_id passes (that is, the current time measured by that clock equals or exceeds abstime) before the condition cond is signaled or broadcasted, or if the absolute time specified by abstime has already been passed at the time of the call. Implementations shall support passing CLOCK_REALTIME and CLOCK_MONOTONIC to pthread_cond_clockwait() as the clock_id argument. When such timeouts occur...[keep final sentence from existing paragraph.] The pthread_cond_clockwait() function is also a cancellation point. Remove paragraph starting at line 51677. Its information is now contained in the updated version of the previous and next paragraphs. Replace paragraph starting at line 51680 with: The pthread_cond_timedwait() function shall be equivalent to pthread_cond_clockwait(), except that it lacks the clock_id argument. The clock to measure abstime against instead comes from the condition variable's clock attribute as set by pthread_condattr_setclock prior to its creation. (Perhaps even add words to the effect of "If no clock attribute has been set then the default is CLOCK_REALTIME", to avoid readers having to refer to pthread_condattr_setclock section.) |
||||||
Tags | issue8 | ||||||
Attached Files | |||||||
|
Issue History | |||
Date Modified | Username | Field | Change |
2021-06-12 14:08 | mikecrowe | New Issue | |
2021-06-12 14:08 | mikecrowe | Name | => Mike Crowe |
2021-06-12 14:08 | mikecrowe | Section | => pthread_cond_clockwait |
2021-06-12 14:08 | mikecrowe | Page Number | => 1563 |
2021-06-12 14:08 | mikecrowe | Line Number | => 51671-51684 |
2021-06-17 15:57 | nick | Note Added: 0005385 | |
2021-06-17 15:58 | nick | Final Accepted Text | => See Note: 0005385 |
2021-06-17 15:58 | nick | Status | New => Resolved |
2021-06-17 15:58 | nick | Resolution | Open => Accepted As Marked |
2021-06-17 15:59 | nick | Tag Attached: issue8 | |
2021-07-02 11:12 | geoffclare | Status | Resolved => Applied |
2024-06-11 09:12 | agadmin | Status | Applied => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |