[1003.1(2013)/Issue7+TC1 0001076]: Cancellation Points
The following issue has been SUBMITTED.
==
http://austingroupbugs.net/view.php?id=1076
==
Reported By:torvald
Assigned To:
==
Project:1003.1(2013)/Issue7+TC1
Issue ID: 1076
Category: Base Definitions and Headers
Type: Enhancement Request
Severity: Comment
Priority: normal
Status: New
Name: Torvald Riegel
Organization: Red Hat
User Reference:
Section:Cancellation Points
Page Number:1
Line Number:1
Interp Status: ---
Final Accepted Text:
==
Date Submitted: 2016-09-09 16:12 UTC
Last Modified: 2016-09-09 16:12 UTC
==
Summary:Cancellation Points
Description:
sem_wait is currently part of the "shall occur" list. This is suboptimal:
(1) It adds overhead to the fast paths of any semaphore implementation (ie,
checking for cancellation, which will likely at least require touching an
additional cache line).
(2) It creates an inconsistency with sem_trywait semantics in that
sem_trywait isn't really a "subset" of sem_wait anymore. Something like
"if (sem_trywait(...) != 0) sem_wait(...);" kills cancellation. To be
consistent wrt cancellation, sem_trywait would have to be a cancellation
point too.
(3) Because the implementation is allowed to decide between cancellation
and success when a cancellation request races with unblocking *during* the
execution of sem_wait, the POSIX requirement that sem_wait should be a
cancellation point regardless of whether it blocks is only exploitable by
programs that enforce that the cancellation request is issued before
sem_wait is called. This requires active synchronization, and thus the
program would already have been able to check whether it should continue to
compute or stop. Thus, using this reliably doesn't add functionality that
the program wouldn't be able to implement otherwise.
Desired Action:
I think that the description of when cancellation requests have to be acted
upon could be improved. Without reading the rationale ("Thread
Cancellation Overview", esp. first paragraph of "Cancellation Points"
bullet), it's hard to see that the "may" vs. "shall" lists also allow for
different treatment of the sem_wait issue I described (eg,
pthread_rwlock_rdlock implementations don't need to check).
It seems the cleanest specification of cancellation would be to say that a
function that is considered to have a cancellation point will eventually
act upon a cancellation request, provided that it is blocked.
This adds the forward progress requirement for acting upon a cancellation
request (ie, the "eventually"), and avoids the weasel-wording in the last
sentences of the section (ie, timeouts and when event and cancellation
request happen without enforced ordering). It also avoids having to check
for cancellation in functions that don't block (which will always affect
fast-paths), yet prevents a thread from being blocked indefinitely. It
would not make "shall occur" functions points that can be interrupted
regardless of whether the thread actually makes progress or not.
Whether a particular function is in the "shall" or "may" camp seems pretty
arbitrary (at least, arguably, different programs would benefit from
different functions being in "shall" vs. "may"). Therefore, cancellation
seems more useful as a mechanism for preventing indefinite blocking (ie,
only cancel if blocked) instead of having even deferred cancellation be
something like unconditional interruption at functions arbitrarily
considered safe points (ie, functions in which cancellation points "shall
occur").
==
Issue History
Date ModifiedUsername FieldChange
==
2016-09-09 16:12 torvaldNew Issue
2016-09-09 16:12 torvaldName => Torvald Riegel
2016-09-09 16:12 torvaldOrganization => Red Hat
2016-09-09 16:12 torvaldSection => Cancellation Points
2016-09-09 16:12 torvaldPage Number => 1
2016-09-09 16:12 torvaldLine Number => 1
==
Re: Quoting: is "${foo-'a"b'"}" valid?
On 2016-09-09 09:02:11 -0400, Chet Ramey wrote:
> On 9/9/16 7:44 AM, Vincent Lefevre wrote:
> > On 2016-09-05 19:12:54 +, Mark Galeck wrote:
> >> The standard says in the section 2.2.3 on Double-Quotes and $ :
> >> "even number of unescaped double-quotes or single-quotes, if any,
> >> shall occur".
> >
> > Concerning this point, these even number of double-quotes and even
> > number of single-quotes are fulfilled with the example below:
> >
> > echo "${foo-'a"b'"}"
> >
> > But is this valid?
>
> It's unspecified, so anything goes, as per
>
> http://austingroupbugs.net/view.php?id=221
>
> "For parameter expansions other than the four varieties that provide
> for substring processing, within the string of characters from an
> enclosed "${" to the matching '}', the double-quotes within which
> the expansion occurs shall preserve the literal value of all
> characters, with the exception of the characters double-quote,
> backquote, , and . If any unescaped
> double-quote characters occur within the string, other than in
> embedded command substitutions, the behavior is unspecified."
But this will be only in Issue 8.
http://austingroupbugs.net/view.php?id=221 is about "poor
wording", but I don't see where it the above unspecified
in Issue 7.
And one also has:
"For the four varieties of parameter expansion that provide for
substring processing (see [xref to 2.6.2 Parameter Expansion]),
within the string of characters from an enclosed "${" to the
matching '}', the double-quotes within which the expansion occurs
shall have no effect on the handling of any special characters."
There's no unspecified behavior concerning the double quotes.
So, what about the following?
echo "${foo#'a"b'"}"
--
Vincent Lefèvre - Web:
Re: Quoting: is "${foo-'a"b'"}" valid?
On 9/9/16 7:44 AM, Vincent Lefevre wrote:
> On 2016-09-05 19:12:54 +, Mark Galeck wrote:
>> The standard says in the section 2.2.3 on Double-Quotes and $ :
>> "even number of unescaped double-quotes or single-quotes, if any,
>> shall occur".
>
> Concerning this point, these even number of double-quotes and even
> number of single-quotes are fulfilled with the example below:
>
> echo "${foo-'a"b'"}"
>
> But is this valid?
It's unspecified, so anything goes, as per
http://austingroupbugs.net/view.php?id=221
"For parameter expansions other than the four varieties that provide
for substring processing, within the string of characters from an
enclosed "${" to the matching '}', the double-quotes within which
the expansion occurs shall preserve the literal value of all
characters, with the exception of the characters double-quote,
backquote, , and . If any unescaped
double-quote characters occur within the string, other than in
embedded command substitutions, the behavior is unspecified."
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Quoting: is "${foo-'a"b'"}" valid?
shwares...@aol.com wrote:
||> The standard says in the section 2.2.3 on Double-Quotes and $ :
||> "even number of unescaped double-quotes or single-quotes, if any,
||> shall occur".
||
||Concerning this point, these even number of double-quotes and even
||number of single-quotes are fulfilled with the example below:
||
|| echo "${foo-'a"b'"}"
||
||But is this valid?
|No, it's not valid, that I see... For the purposes of counting the \
|double quote in a"b loses it's special meaning because a single quote \
|stream has been
|started. The double quote after the closing single quote is matched \
That is an interesting question, and what would have been my
thought, too.
|by the double quote after the right brace. ksh is waiting for an additional\
| right
|brace and double quote to be typed to complete the command, it seems, \
|which is proper, and if done should output a"b}. The others appear \
Yes, i would also think the } is double-quote quoted, so this
should have ended up as a"b} and then awaiting more input.
I really wondered how the other interpretations materialize
(except being (bug-)compatible with each other)?
--steffen
