From: Ian Lance Taylor <iant@google.com>
To: John Steele Scott <toojays@toojays.net>
Cc: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Subject: Re: C++ exceptions with many threads and no memory.
Date: Tue, 04 Mar 2014 06:36:00 -0000 [thread overview]
Message-ID: <CAKOQZ8y0WBXmq-=bnzjxXcg9WthPCzRvw6Vu8H-AGDEcYjVeWg@mail.gmail.com> (raw)
In-Reply-To: <lf1qfl$tf5$1@ger.gmane.org>
On Mon, Mar 3, 2014 at 3:53 AM, John Steele Scott <toojays@toojays.net> wrote:
>
> When comparing this to GCC's exception handling, I find that libstdc++ calls malloc() whenever an exception is thrown, and falls back to statically allocated memory only when malloc fails. Only 64 statically allocated exceptions may be in flight at once, and if this limit is violated, std::terminate() is called.
>
> This seems like quite a brittle behaviour to me. I guess not often seen as a problem in practice because Linux overcommit usually ensures malloc() won't fail (although if it does, then you have to take your chances with the oom-killer anyway).
>
> There doesn't seem to be any way around this, is there? Do GCC developers consider it a bug?
If you have a good proposal for how to handle this situation, I'm sure
that GCC developers would consider it.
It seems pretty tough to handle large numbers of exceptions when
malloc fails. And since it is such an unusual condition, I don't
think it would be a good idea to address it in a manner that penalizes
performance in ordinary conditions.
Ian
next prev parent reply other threads:[~2014-03-04 6:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-03 11:53 John Steele Scott
2014-03-04 6:36 ` Ian Lance Taylor [this message]
2014-03-04 10:06 ` John Steele Scott
2014-03-05 8:35 ` John Steele Scott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKOQZ8y0WBXmq-=bnzjxXcg9WthPCzRvw6Vu8H-AGDEcYjVeWg@mail.gmail.com' \
--to=iant@google.com \
--cc=gcc-help@gcc.gnu.org \
--cc=toojays@toojays.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).