[boost] Re: Attempting resolution of Threads & Exceptions Issue

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-08-17 11:10:08

Peter Dimov wrote:
[...]
> > That is "usually" done using things like "validation sentinel", etc.
> > Now, I think that it is reasonable to assume that our fancy C++ wrapper
> > would simply "translate" it to std::invalid_argument exception.
> 
> Our badly designed fancy C++ wrapper, you mean. :-)

I mean hypothetical mutex::unlock() function from hypothetical
<thread> header.  BTW, I hope that it will also have defined
pthread_mutex_t* mutex::c_mutex() function... meant to provide 
support to some "C" code using "just" facilities defined in 
hypothetical <cthread> header -- basically adopted <pthread>. ;-)

> > So,
> > unless your "never throws" function has throw() ES, there is indeed a
> > chance that "you'll get a nicely packaged std::invalid_argument out of
> > a function that is specified to not throw", I believe.
> 
> Yes, there is a (slim) chance to get that. ....

It's time for my Butenhof's-quote-of-the-day, I guess. ;-)

"From: David Butenhof (David.Butenhof_at_[hidden])
 Subject: Re: mutex problem using DECthreads 
 Newsgroups: comp.programming.threads

 Rajanish Calisa wrote:

 > 
 > "Joerg Faschingbauer" <jfasch_at_[hidden]> wrote in message
 > news:m3u1zaalgm.fsf_at_jfasch.faschingbauer.com...
 >> >>>>> "Rajanish" == Rajanish Calisa <rcalisa_at_[hidden]> writes:
 >>
 >> Rajanish>     // Assertion fails in the lock method.
 >> Rajanish>     bool lock() { assert( pthread_mutex_lock() == success ); }
 >>
 >> I hope you're not going to define NDEBUG when you build for release,
 >> do you?
 >>
 > No I don't. Why?

 Why? Because if you compile with NDEBUG, your mutex lock will go away. 
 That's likely to have a damaging effect on your application. ;-)

        status = pthread_mutex_lock (...);
        assert (status == 0);

 would be more common. Often, people who use assert() don't intend to ship 
 code with assertions enabled, since (depending on how paranoid you are 
 about asserting things) they may represent a substantial performance drain. 
 My thread library, for example, has assertions for everything, everywhere. 
 We routinely run our test system and some test applications with asserts 
 enabled because it helps to catch internal inconsistencies that would never 
 be noticed otherwise, or that would appear in inconvenient ways. But it 
 performs like a dog so we always build production libraries with NDEBUG. 
 (Which leaves a much smaller set of explicit "bugchecks" to catch a few 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 really severe internal errors that "can't happen".)"
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

regards,
alexander.