Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.std.c Subject: Re: OOM and N2471 (Stackable, thread local, signal guards) Date: Fri, 08 May 2020 07:56:23 -0700 Organization: A noiseless patient Spider Lines: 48 Message-ID: <86ftcazd9k.fsf@linuxsc.com> References: <7fd2mg-7bh1.ln1@wilbur.25thandClement.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="b5e8c1925c1f5a62ad5a60468d6da6c6"; logging-data="2561"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19oBvB1QFkji2BbDOfh2FEQkuUCevBztTA=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:7EHJrGhjpGNGopq5YOVUSOMGEiU= sha1:won6Phy51j315Hm48X+PwyNemM8= Xref: csiph.com comp.std.c:6107 William Ahern 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.)