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

    From William Ahern@21:1/5 to All on Wed Apr 8 19:21:59 2020
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tim Rentsch@21:1/5 to William Ahern on Fri May 8 07:56:23 2020
    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.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Ahern@21:1/5 to Tim Rentsch on Fri May 8 13:01:46 2020
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)