Help: Unwinding the C++ stack...throw, longjmp & threads

[craig@jcb-sc.com]

>Thanks Craig, for a long and thoughtful essay.
>A couple of points of response.  First off, some attention to the 
>rest of the thread would be required to understand the context of the
>text quoted above.  

Indeed, I thought that might be the case, and called attention to
that fact.

>Part of that context was contained in the rest of the excerpted
>post, which went on to describe a scheme for solving the problem
>that I understood to be proposed by Joe:  a) preserving the
>legacy malloc() interface and b) avoiding even the possibility of
>a memory leak in the presence of asynchronous exceptions.
>
>A couple of people, including you, have jumped on the word
>choice "lost in the noise", but nobody seemed to object to the
>argument that one could, after all, design a malloc that didn't
>have the possibility of leaking in the presence of asynchronous
>exceptions.

My main concern is to reinforce resistance among GCC developers
(and, for that matter, developers of *any* system upon which other
systems are deployed) against accepting designs and/or implementations
that have windows such as illustrated by that sample code.  (Or, for
that matter, accepting new features that expose such windows to
programmers on the theory that "programmers should know better" --
but that gets further into my other controversial stances, such
as wanting compiler defaults that favor stability and predictability,
rather than performance.)

>Clearly, I am not saying that the time window is lost in the noise,
>but rather that the *combination* of the time window for a signal
>at just that juncture, with a signal that is a case to throw(),
>with a one-time memory leak (of small size - otherwise make use
>of the other interface), with an architecture that isn't reclaiming
>the memory through other means after such a throw - all of this
>combined is less likely to cause a visible performance problem
>in practice than say, a bug due to a compiler error.  Perhaps
>you disagree with that, but at least please disagree with my
>actual opinion.

I'm not sure I disagree with that anyway.   I missed that you were
limiting your commentary to performance issues -- sorry about that.

>You've really raised the stakes in your commentary - talking about
>missile systems and the like.
>The idea that designing exception safe classes makes
[...]
>their use safe in the presence of exceptions, independently
>of a context, is, I think, an illusion.
[...]
>Well I agree with you - at the level of stakes you are  talking
>about, most programs and programmers are broken.  However, I may
>have some differences regarding assessment of where the greatest risks
>originate.

FWIW, I think we agree about that, though you probably have more
experience/expertise than I do.  My raising the missile-systems
issue was just an extreme example to illustrate the general thrust
of my post: GCC developers should *never* accept a less-than-robust
design for code generation.  That's because GCC generates code for
projects ranging from games to, if not missile systems, radiation-therapy
machines and the like.  So GCC developers are *fundamentally* incapable
of assessing risks vis-a-vis code-generation issues, since they have,
by definition, no information as to how any given use of GCC will be
made, vis-a-vis the pertinent risks.

It seems you weren't proposing such a design be accepted, in which
case I definitely spoke out of turn.  Sorry!

        tq vm, (burley)