This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [3.3] Followup to C++ forced unwinding

On Sat, May 03, 2003 at 01:20:57AM +1000, Fergus Henderson wrote:
> > | I'd ever so much rather debug a
> > | why-didn't-my-thread-go-away bug than a
> > | why-is-my-data-in-an-inconsistent-state bug.
> > 
> > strongly seconded.
> I agree that ignoring "catch(...)" handlers for cancels is not going to fly.
> I agree about which bug I'd prefer to debug.
> But my intuition is that I think that very few of those million lines
> of until-now exception-safe ISO-conformant code would break from an
> implicit rethrow if/when a cancel got swallowed -- I think a lot more
> would break from an implicit terminate() in the same situation.

Reams of code would be broken in either case.  How much in each 
is debatable, and moot. 

If code is to be broken, it should be broken as loudly as possible.
At compile time, if possible.  Automatically re-throwing violates
that principle.

It's best just not to break the code at all, and that is also easily 
implementable.  Apparently all it needs is to give the cancelled 
thread defined semantics for all plausible operations.  That also 
ought to be easy.  

Nobody has posted any reason why the state of a cancelled thread 
should be so corrupted, beyond "read the code", without any details
even of where this code is.  Can somebody please post the code or
a URL, and an explanation of why it must be so?

Thus far, nobody has more than hinted at any rationally sound reason
for breaking all exception-safe libraries used in thread contexts.  
We really should see the details before this goes any farther.

Nathan Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]