Date: Wed, 14 Jun 2023 12:56:16 -0500
From: "G. Branden Robinson via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <20230614175616.ilqpqzpbeiipu7s7@illithid>
| The question is, did thread A receive SIGINT or not?
No, that isn't the question at all. That's a simple race, and
irrelevant to the current discussion.
| Is the current draft language therefore redundant? Can lines 59787-8 be
| deleted without damaging anything?
Those line numbers in which draft? In the current draft (the most recent
available one, Issue 8 draft 3) those are the (whole) DESCRIPTION section of
pthread_setspecific() - and something tells me that's not what you're
proposing removing.
In e-mail, it is generally better to quote the lines, than line numbers,
that's something everyone can understand, and can know exactly which text
is in question - at the minute I'm not sure what you're referring to.
For large sections, unless some specific wording therein is important,
it's OK to just quote the first part and the ending, we can find the
whole thing in the draft that way. But do always make it clear which
section (for XSH 3 and XCU 3 give the function/utility name, elsewhere
the section number, and ideally its title, as numbers sometimes alter).
| Thanks for emphasizing the narrow scope. I've tried to direct my reply
| accordingly.
Except the narrow scope related to what happens when the signal mask is
changed to unblock signals that were blocked, and in particular, when one
(or more) of those signals are pending. You concentrated on the exact
opposite case, when blocking a signal, which has no particular issues at all.
The issue here is that the current standard contains language which while
clear enough about its intent, is logically absurd (it requires something
to be done after, and at the same time before, something else). We could
just leave it alone - no-one is going to doubt what it means. But fixing
it would be better - and we now have language that does that which works.
Beyond that, an APPLICATION USAGE section is being added (technically, it
is already there, but just says "None" - that "None" is being replaced by
other text) to explain to application writers what can happen, to avoid
misunderstandings. The wording of that is the most recent topic of
discussion, but that's settled now too.
In both cases, naturally, unless someone else sees a problem with them.
There never really was anything substantive here, it is all just wording
things properly.
kre
