From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-15 07:56:50
> From: "Scott McCaskill" <scott_at_m...>
> ----- Original Message -----
> From: "Beman Dawes" <bdawes_at_a...>
> To: <boost_at_[hidden]>; <boost_at_[hidden]>
> Sent: Tuesday, August 14, 2001 8:50 PM
> Subject: Re: [boost] thread::join()
> > At 02:51 PM 8/14/2001, Scott McCaskill wrote:
> > >Shouldn't thread::join() throw an exception if a thread tries to join
> > >itself? Right now, it will deadlock in such a situation.
> > It is a documented precondition (Requires), so violation is undefined
> > behavior.
> Ok, but what is the rationale for this? Efficiency?
yes (with respect to pthread_join()):
"The pthread_join() function *may* fail if:
[EDEADLK] A deadlock was detected or the value
of thread specifies the calling thread. "
"Tradeoff Between Error Checks and Performance Supported
Many of the error checks were made optional in order to
let implementations trade off performance versus degree
of error checking according to the needs of their specific
applications and execution environment. As a general rule,
errors or conditions caused by the system (such as
insufficient memory) always need to be reported, but
errors due to an erroneously coded application (such as
failing to provide adequate synchronization to prevent a
mutex from being deleted while in use) are made optional.
A wide range of implementations is thus made possible.
For example, an implementation intended for application
debugging may implement all of the error checks, but an
implementation running a single, provably correct
application under very tight performance constraints in
an embedded computer might implement minimal checks. An
implementation might even be provided in two versions,
similar to the options that compilers provide: a full-
checking, but slower version; and a limited-checking,
but faster version. To forbid this optionality would
be a disservice to users.
By carefully limiting the use of ''undefined behavior''
only to things that an erroneous (badly coded) application
might do, and by defining that resource-not-available
errors are mandatory, this volume of IEEE Std 1003.1
ensures that a fully-conforming application is portable
across the full range of implementations, while not
forcing all implementations to add overhead to check for
numerous things that a correct program never does."
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk