Re: request for clarification on Open Group Base Specifications Issue 7: Canc...
I don't see the interface invoked to block the thread is allowed to cancel the request completely, simply that the interface may return to reduce serialization latencies for the 2 bullet point cases and the cancellation honored at the next plausible point in the code path, in accordance with explanation of XRAT B.2.9.5, (P3657, L125092-7, C165.pdf), rather than handle the cancel immediately before honoring the expiration and perhaps leave some shared resources in an inconsistent state. However, application code may be written so there is no "next plausible point" because it goes into a loop that does not use any of the thread cancellation interfaces, so it will look like the request is not being acted upon. If threading is non-preemptive, an infinite loop of this nature means it won't be acted upon at all, as extreme case. What seems to be missing there is a requirement that the interfaces that are allowed to resume execution check for cancellation requests being active immediately before they return, and honor them, in addition to when they begin execution and honor them when they want to. This has the effect the thread resumes normal execution, as currently stated, until the end of the interface invocation. In a message dated 6/9/2017 1:53:32 P.M. Eastern Daylight Time, dimitri.staess...@ugent.be writes: Dear, There is a paragraph in the Base Specifications regarding Cancellation Points that seems to leave some room for interpretation, with rather dire consequences: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html It concerns the following paragraph: Whenever a thread has cancelability enabled and a cancellation request has been made with that thread as the target, and the thread then calls any function that is a cancellation point (such as _pthread_testcancel()_ (http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_testcancel.html) or _read()_ (http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html) ), the cancellation request shall be acted upon before the function returns. If a thread has cancelability enabled and a cancellation request is made with the thread as a target while the thread is suspended at a cancellation point, the thread shall be awakened and the cancellation request shall be acted upon. It is unspecified whether the cancellation request is acted upon or whether the cancellation request remains pending and the thread resumes normal execution if: * The thread is suspended at a cancellation point and the event for which it is waiting occurs * A specified timeout expired before the cancellation request is acted upon. In the newest glibc implementation (2.25), the clause "It is unspecified whether the cancellation request is acted upon if ... a specified timeout expired" is taken against the first statement of the paragraph. The new implementation of pthread_cond_timedwait() does not act upon a pending cancellation request if the abstime (specified using the monotonic clock) has already expired. See the bug report and discussion here: https://sourceware.org/bugzilla/show_bug.cgi?id=21291 >From the way this paragraph is written, I think the interpretation by the developer is, however unpalatable, a valid one. However my interpretation is that the first statement (that a cancellation request that is pending before any cancellation point is entered, must always be acted upon, irrespective of any input to the cancellation point) is non-negitiable and the clauses are only valid when there was no pending cancellation request at the time of entry into the cancellation point. This would be a much more robust interpretation. Can you please clarify how this should be interpreted? thank you very much for your assistance, Dimitri Staessens Ghent University-imec
Re: [1003.1(2013)/Issue7+TC1 0001045]: Issues with "cd -"
In a message dated 6/10/2017 10:16:54 A.M. Eastern Daylight Time, nore...@msnkbrown.net writes: (it's not even clear if such arrays of bytes may be stored in shell variables). This is allowed, clearly, but you currently have to jump through hoops to make use of an arbitrary sequence when the locale is 'C' or 'POSIX', which is the unclear part. The shell is adding the $'...' string form to address setting the values or as constants otherwise, but some aspects of using them still problematic. These problems have been discussed ad nauseam in other bugs so I won't elaborate. Using the values in substitutions may have additional context or implementation sensitive restrictions.
[1003.1(2013)/Issue7+TC1 0001045]: Issues with "cd -"
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1045 == Reported By:stephane Assigned To: == Project:1003.1(2013)/Issue7+TC1 Issue ID: 1045 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Interpretation Required Name: Stephane Chazelas Organization: User Reference: Section:cd utility Page Number:2529 Line Number:81569 Interp Status: Proposed Final Accepted Text:http://austingroupbugs.net/view.php?id=1045#c3749 == Date Submitted: 2016-04-23 15:07 UTC Last Modified: 2017-06-10 14:14 UTC == Summary:Issues with "cd -" == Relationships ID Summary -- related to 0001047 Unspecified behaviour for cd == -- (0003758) stephane (reporter) - 2017-06-10 14:14 http://austingroupbugs.net/view.php?id=1045#c3758 -- Thanks. The resolution is fine to be. About the application usage section, I'd just add a note that since a file path can be any array of non-null bytes, the case $dir in /*) is currently not clearly specified in the case where those bytes don't form valid characters (it's not even clear if such arrays of bytes may be stored in shell variables). In any case, that's something that would have to be addressed in a separate issue. But possibly, that means that the example above would have to be amended to have a "LC_ALL=C" read, parsed and run before the "case" command is run. Also, as noted on the mailing list, we may want to add similar usage sections for the other cases where "-" is a problem (most text utilities and more). Issue History Date ModifiedUsername FieldChange == 2016-04-23 15:07 stephane New Issue 2016-04-23 15:07 stephane Name => Stephane Chazelas 2016-04-23 15:07 stephane Section => cd utility 2016-04-23 15:07 stephane Page Number => 2529 2016-04-23 15:07 stephane Line Number => 81569 2016-04-25 10:13 joerg Note Added: 0003173 2016-04-25 10:42 stephane Note Added: 0003174 2016-04-25 10:47 stephane Note Edited: 0003174 2016-04-25 10:47 stephane Note Edited: 0003174 2016-04-25 10:48 geoffclare Note Added: 0003175 2016-04-25 10:49 geoffclare Note Edited: 0003175 2016-04-25 11:19 geoffclare Note Edited: 0003175 2016-04-25 11:34 geoffclare Relationship added related to 0001047 2016-05-12 14:17 Vincent LefevreNote Added: 0003226 2017-05-25 16:33 geoffclare Note Added: 0003749 2017-05-25 16:35 geoffclare Note Edited: 0003749 2017-05-25 16:36 geoffclare Interp Status => Pending 2017-05-25 16:36 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1045#c3749 2017-05-25 16:36 geoffclare Status New => Interpretation Required 2017-05-25 16:36 geoffclare Resolution Open => Accepted As Marked 2017-05-25 16:36 geoffclare Tag Attached: tc3-2008 2017-06-01 15:40 geoffclare Note Edited: 0003749 2017-06-01 15:43 Don Cragun Note Added: 0003750 2017-06-01 15:44 Don Cragun Note Deleted: 0003750 2017-06-02 13:34 ajosey Interp StatusPending => Proposed 2017-06-02 13:34 ajosey Note Added: 0003752 2017-06-10 14:14 stephane Note Added: 0003758 ==
Re: [1003.1(2016)/Issue7+TC2 0001142]: pread(2) and pwrite(2) should be async...
Sorry for the confusion, I was looking at some code recently that appears to initialize a new file description with independent seek pointer from an open handle as part of what they call a dup(). It does save having to track the path string so open(path, ...) doesn't have to be used instead. I should have used _dup() or hcopy() instead, as the dwim version for the sequence. In a message dated 6/6/2017 8:26:17 A.M. Eastern Daylight Time, casper@oracle.com writes: >-- > (0003753) shware_systems (reporter) - 2017-06-06 12:14 > http://austingroupbugs.net/view.php?id=1142#c3753 >-- >While this looks reasonable, the restriction on pread() and pwrite() of not >disturbing the seek position is problematic. It means an effective >dup();lseek();read() or write();close() sequence occurs on each invoke. This doesn't make sense: dup() creates a file pointer with: osame file pointer (that is, both file descriptors share one file pointer) lseek() on a dup()'ed file will move the lseek on the original file pointer as well. (That makes it possible to write an "lseek(1)" utility which can be used to change the file pointer for inherited file descriptors) Casper
