Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #6072 > unrolled thread

OOM and N2471 (Stackable, thread local, signal guards)

Back to article view | Back to comp.std.c

Contents

  OOM and N2471 (Stackable, thread local, signal guards) William Ahern <william@25thandClement.com> - 2020-04-08 19:21 -0700
    Re: OOM and N2471 (Stackable, thread local, signal guards) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-08 07:56 -0700
      Re: OOM and N2471 (Stackable, thread local, signal guards) William Ahern <william@25thandClement.com> - 2020-05-08 13:01 -0700

#6072 — OOM and N2471 (Stackable, thread local, signal guards)

I just read through N2471, a proposal to add signal guards to C and C++:

  http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2471.pdf

One of the stated goals is to be able to catch OOM events in C++ code that
no longer throws C++-style exceptions on allocation failure. See, e.g., sec.
1.1 item 4.

However, the proposal disallows invoking async signal safe functions within
guarded code sections. Sec. 3.

Traditionally the "default allocator" in C++ uses malloc, and malloc is not
async signal safe. E.g, "on Microsoft Windows, many of the Win32 APIs which
appear equivalent to POSIX ones in the list above are NOT async signal safe
because they call malloc() e.g. CreateFile()." ibid.

The prohibition on async signal functions in tandem with the expectation
(and goal) for guarded code to use the C++ new operator seems incongruous. I
realize that the new operator is technically a black box; strictly speaking
malloc being async signal safe is irrelevant to the async signal safety of
the C++ new operator (at least from the perspective of the C standard). But
it leaves me with a suspicion that some very important aspects of this
proposal haven't been clearly thought through. Even the proposal seems to
equivocate dynamic memory allocation with async signal safety: "potential
dynamic memory allocation equals lack of async signal safety." ibid.

Am I alone? Am I missing something?

[toc] | [next] | [standalone]

#6107

William Ahern <william@25thandClement.com> writes:

> I just read through N2471, a proposal to add signal guards to C and C++:
>
>   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2471.pdf
>
> One of the stated goals is to be able to catch OOM events in C++ code that
> no longer throws C++-style exceptions on allocation failure.  See, e.g., sec.
> 1.1 item 4.
>
> However, the proposal disallows invoking async signal safe functions within
> guarded code sections.  Sec. 3.
>
> Traditionally the "default allocator" in C++ uses malloc, and malloc is not
> async signal safe.  E.g, "on Microsoft Windows, many of the Win32 APIs which
> appear equivalent to POSIX ones in the list above are NOT async signal safe
> because they call malloc() e.g. CreateFile()." ibid.
>
> The prohibition on async signal functions in tandem with the expectation
> (and goal) for guarded code to use the C++ new operator seems incongruous.  I
> realize that the new operator is technically a black box;  strictly speaking
> malloc being async signal safe is irrelevant to the async signal safety of
> the C++ new operator (at least from the perspective of the C standard).  But
> it leaves me with a suspicion that some very important aspects of this
> proposal haven't been clearly thought through.  Even the proposal seems to
> equivocate dynamic memory allocation with async signal safety:  "potential
> dynamic memory allocation equals lack of async signal safety." ibid.
>
> Am I alone?  Am I missing something?

Perhaps the best way I might answer this question is to say I
don't have any confidence in the proposal.  About the best I can
say for it is they make it clear that they don't like what Posix
does in this area.  Almost everything else they say is not clear,
at least not to me.  In response to your suspicion that "some
very important aspects of this proposal haven't been clearly
thought through", well, for me, suspicion is too mild a word;  I
believe many aspects of this proposal have not been clearly
thought through, and very likely some of the more important
or most important ones are included in that.

Incidentally, the phrasing of the sentence with "equivocate" in
it seems a bit off to me.  What I think you mean is the proposal
is confused about the question of whether dynamic memory
allocation is async signal safe.  If that is what you mean, I got
it, but it took me several minutes to get there.  And if that is
not what you mean then I don't know what you mean.  (None of that
affects my reaction to the proposal.)

[toc] | [prev] | [next] | [standalone]

#6117

Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> William Ahern <william@25thandClement.com> writes:
<snip>
>> proposal haven't been clearly thought through.  Even the proposal seems to
>> equivocate dynamic memory allocation with async signal safety:  "potential
>> dynamic memory allocation equals lack of async signal safety." ibid.
>>
>> Am I alone?  Am I missing something?
<snip>
> Incidentally, the phrasing of the sentence with "equivocate" in
> it seems a bit off to me.  What I think you mean is the proposal
> is confused about the question of whether dynamic memory
> allocation is async signal safe.  If that is what you mean, I got
> it, but it took me several minutes to get there.  And if that is
> not what you mean then I don't know what you mean.  (None of that
> affects my reaction to the proposal.)

Your interpretation is correct. Perhaps I intended to write "equivocate...
with lack of async signal safety". I stumbled over that bit myself
re-reading it. But, yes, what I was getting it was that the proposal seemed
confused on this point.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.std.c

csiph-web