Upcoming ISO/IEC <thread>... and <pthread.h> -> <cthread> transition ;-)
Alexander Terekhov
"William E. Kempf" wrote:
>
> Alexander Terekhov said:
> >
> > Alexander Terekhov wrote:
> >>
> >> "William E. Kempf" wrote:
> >> [...]
> >> > The motivations are backwards here, though. If the C++ language
> >> adopts a threading library, POSIX systems will have a lot of
> >> motivation for defining a POSIX C++ binding, or at the very least,
> >> making a particular implementation's POSIX binding compatible with
> >> the C++ threading.
> >>
> >> How about moving this discussion to c.p.t.?
> >
> > Well, just in case... <Forward Quoted>
>
> Thanks... I currently can't access c.p.t. in any reasonable manner. I'm
> working to rectify this, but in the mean time, I appreciate the cross
> post.
>
> > David Butenhof wrote:
> >>
> >> Alexander Terekhov wrote:
> >>
> >> >> > "William E. Kempf" wrote:
> >> >> The motivations are backwards here, though. If the C++ language
> >> adopts a threading library, POSIX systems will have a lot of
> >> motivation for defining a POSIX C++ binding, or at the very least,
> >> making a particular implementation's POSIX binding compatible with
> >> the C++ threading.
> >>
> >> Right now, the C++ language has, by default and convention, a POSIX
> >> binding; 1003.1-2001. The C and C++ languages are sufficiently
> >> interoperable that this presents only a few restrictions on the use by
> >> C++ code, around exceptions and member functions. OK, so the thread
> >> start routine needs to be 'extern "C"' -- a minor inconvenience. OK,
> >> so there's no portable standard on interoperability between POSIX
> >> cleanup and C++ exceptions, and I'll resist suggesting that only an
> >> idiot would fail to make them completely compatible and interoperable;
> >> but at least most people can be educated to realize that they ought to
> >> be.
>
> The cleanup issues are some of the bigger ones, IMHO. And my experience
> indicates there are a lot of people out there that Mr. Butenhoff would
> consider "idiots", I think. But I agree with what he's said.
>
> >> The big hurdle for a true C++ binding is that the current state of
> >> affairs is "good enough" for most people, and the political process of
> >> developing a full native C++ binding would be painful. (Remember, it's
> >> not just saying that the thread::create method takes a class member at
> >> which the thread will start... it means reviewing every method and
> >> template in the STL to determine which have thread safety
> >> requirements, and deciding precisely what those requirements are and
> >> how to meet them. Then there's the matter of cancellation points...
> >> and so forth.)
>
> Most STL libraries are thread-safe today, so the analysis there wouldn't
> be too difficult. It just needs to be stated explicitly in the standard.
> Cancellation points are another issue... but I don't think C++ will add
> too many to the list already provided by POSIX.
>
> >> When and if the C++ standard adds true thread support, that will be,
> >> by default and in practice, the thread binding for C++; whether the
> >> underlying thread environment is POSIX, Win32, or something else. This
> >> is great, as long as it doesn't do or say anything stupid, but it
> >> still leaves a few loopholes because inevitably people will continue
> >> to write applications that mix languages. Mixing C and C++ has never
> >> been a problem; but if the thread model in C++ is radically different,
> >> it could become a problem.
>
> Absolutely agreed. I've said all along that Boost.Threads has to be very
> aware of what POSIX says. We can not deviate in any way from POSIX that
> will result in conflicts between the threading systems.
>
> >> Furthermore, there's a missing piece that
> >> neither POSIX 1003.1-2001 plus ISO C++ 2005 (or whatever), or even
> >> 1003.1-2001 plus a hypothetical "1003.C++" will necessarily (or even
> >> likely) supply -- and that's how the two interoperate.
>
> Agreed, but that's the case today when mixing languages. There are a lot
> of areas which are left unspecified, even when the languages being mixed
> are C and C++.
>
> >> If C++ or 1003.C++ says that thread::cancel raises an exception, and
> >> 1003.1 says that pthread_cancel() invokes cleanup handlers, does that
> >> mean that cancelling a thread with pthread_cancel() will trigger
> >> catch(...), or even destructors? Well, maybe not. This could more
> >> easily be solved with a 1003.C++, perhaps, since at least the two
> >> standards are in a family. Since the C++ standard is unlikely to
> >> mention POSIX any more than now, it's unlikely to provide any
> >> guarantees.
>
> No gaurantees. But with a C++ definition, one can at least hope that
> implementations will try and deal with these cross-language binding issues
> in some reasonable manner.
>
> >> Perhaps that would provide an opportunity for a smaller POSIX project,
> >> though; a PROFILE that would chink the holes where the two walls meet.
> >> In effect, specifying a "POSIX platform" supporting both threads and
> >> C++ that simply says "C++ cancellation is the same as POSIX
> >> cancellation", "POSIX cleanup handlers are logically and semantically
> >> the same as C++ object destructors", and "POSIX cancellation is
> >> visible as a C++ exception".
>
> Reasonable things for POSIX to do, or at least consider, IMO.
>
> --
> William E. Kempf
>
> ------------------------ Yahoo! Groups Sponsor ---------------------~-->
> Get A Free Psychic Reading! Your Online Answer To Life's Important Questions.
> http://us.click.yahoo.com/Lj3uPC/Me7FAA/uetFAA/EbFolB/TM
> ---------------------------------------------------------------------~->
>
> Info: <http://www.boost.org>
> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
> Unsubscribe: <mailto:boost-users...@yahoogroups.com>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Alexander Terekhov
-------- Original Message --------
Newsgroups: gmane.comp.lib.boost.user
Subject: Re: boost::mutex::scoped_lock conventions
Date: Wed, 21 May 2003 21:04:49 +0200
"William E. Kempf" wrote:
[...]
> >> How about moving this discussion to c.p.t.?
> >
> > Well, just in case... <Forward Quoted>
>
> Thanks... I currently can't access c.p.t. in any reasonable manner. I'm
> working to rectify this,
http://news.cis.dfn.de might help. ;-)
but in the mean time, I appreciate the cross
> post.
I'll wait a day or two and post a reply addressing some of your points
to comp.programming.threads. You might also want to keep an eye on the
discussion of "validity" of the following DCSI** pattern (not exposing
thread_specific_ptr::release() or thread_specific_ptr::reset() to the
clients... Butenhof believes that since <quote>You at least need to be
sure all threads are "done" with the current key and will never read it
again, because pthread_key_delete() cannot invalidate the key</quote>,
the clients ("individual threads") should <quote>confirm that
synchronization by clearing their value for the key</quote>).
class stuff { /* ... */ };
class thing {
public:
thing(/* ... */) : /* ... */ stuff_shared_ptr(0) /* ... */ { /*...*/ }
~thing() { /* ... */ delete stuff_shared_ptr; /* ... */ }
/* ... */
const stuff & stuff_instance();
/* ... */
private:
/* ... */
mutex stuff_mtx;
stuff * stuff_shared_ptr;
thread_specific_ptr<stuff, no_cleanup> stuff_thread_ptr;
/* ... */
};
const stuff & thing::stuff_instance() { // "lazy" one
stuff * ptr;
if (0 == (ptr = stuff_thread_ptr.get())) {
{ mutex::guard guard(stuff_mtx);
if (0 == (ptr = stuff_shared_ptr))
ptr = stuff_shared_ptr = new stuff(/*...*/);
}
stuff_thread_ptr.set(ptr);
}
return *ptr;
}
the details can be found in "Double-checked locking and memory barriers"
c.p.t. thread.
regards,
alexander.
**) DCSI stands for double-checked serialized initialization. Two variations
are known corrently: DCSI-MBR and DCS-TSD (TLS). There's also another
DC-"pattern" -- double-checked concurrent initialization [DCCI]; using
atomic<> with barriers and "CAS".
--
"// Possible implementation for <pthread.h> and <cthread>
#include <thread>
// for <cthread>, please remove the using-directive
using namespace std;"
-- ...
Alexander Terekhov
> "William E. Kempf" wrote:
[...]
> to comp.programming.threads.
Next week. Well, for now, please see the message forwarded below.
> You might also want to keep an eye on the
> discussion of "validity" of the following DCSI** pattern (not exposing
> thread_specific_ptr::release() or thread_specific_ptr::reset() to the
> clients... Butenhof believes that since <quote>You at least need to be
> sure all threads are "done" with the current key and will never read it
> again, because pthread_key_delete() cannot invalidate the key</quote>,
> the clients ("individual threads") should <quote>confirm that
> synchronization by clearing their value for the key</quote>). ....
http://opengroup.org/austin/mailarchives/austin-review-l/msg01511.html
(Subject: Defect in XSH pthread_setspecific)
http://opengroup.org/austin/mailarchives/austin-review-l/msg01513.html
(Subject: Defect in XSH pthread_key_delete)
<Forward Inline>
-------- Original Message --------
Message-ID: <3ECF8878...@web.de>
Newsgroups: comp.std.c++
Subject: Re: Exception handling... it's time to fix the standard
References: <3EC0ECAA...@web.de> <3EC382B0...@web.de>
< "self-correction" [well, and "move up" ;-) ] >
> > Finally, I believe
> > that the standard should say that 'execution of each and
> > every thread' [initial/main including] shall be done "as if"
> >
> > whatever run(...whatever...) throw(std::thread_exit,
> > std::thread_cancel);
>
> Sorry, std::thread_exit_request and std::thread_cancel_request
> (std::thread_termination_request aside for a moment ;-) ):
>
> http://groups.google.com/groups?selm=3EC258F8.AE7DF214%40web.de
>
> <quote>
>
> I can see nothing in the POSIX standard that would prohibit
> the following implementation of pthread_exit():
>
> extern "C" void pthread_exit(void * ptr) {
> std::thread_exit(ptr);
> }
Sorry, I meant:
#define PTHREAD_CANCELED std::thread_canceled()
extern "C" void pthread_exit(void * ptr) throw(std::thread_termination_request) {
(ptr == PTHREAD_CANCELED) ? std::thread_cancel() : std::thread_exit(ptr);
}
>
> using something along the lines of: (from the "std" namespace)
struct thread_canceled {
operator void * () { return &unique; }
static thread_canceled unique;
};
>
> class thread_termination_request : public std::exception ...
> class thread_cancel_request : public std::thread_termination_request ...
> class thread_exit_request : public std::thread_termination_request ...
>
> template<typename T>
> class thread_exit_value : public std::thread_exit_request ...
>
> template<typename T>
> void thread_exit(T value) {
> assert(std::thread_self().can_exit_with<T>());
> throw thread_exit_value(value);
> }
template<>
void thread_exit(std::thread_canceled) {
thread_cancel();
}
void thread_cancel() {
throw std::thread_cancel_request();
}
("or something like that").
regards,
alexander.
--
"Stroustrup is not a disinterested party in that debate."
-- [Subject: Re: c#] http://tinyurl.com/ckem
Alexander Terekhov
Alexander Terekhov wrote:
>
> <Forward-Quoted source=Boost>
>
> "William E. Kempf" wrote:
> > >> The big hurdle for a true C++ binding is that the current state of
> > >> affairs is "good enough" for most people, and the political process of
> > >> developing a full native C++ binding would be painful. (Remember, it's
> > >> not just saying that the thread::create method takes a class member at
> > >> which the thread will start... it means reviewing every method and
> > >> template in the STL to determine which have thread safety
> > >> requirements, and deciding precisely what those requirements are and
> > >> how to meet them. Then there's the matter of cancellation points...
> > >> and so forth.)
> >
> > Most STL libraries are thread-safe today, so the analysis there wouldn't
> > be too difficult.
Well, <http://lists.boost.org/MailArchives/boost/msg47701.php>.
> > It just needs to be stated explicitly in the standard.
> > Cancellation points are another issue... but I don't think C++ will add
> > too many to the list already provided by POSIX.
The current C++ Std is in conflict with POSIX, to begin with. The C++
standard says that almost the entire C library doesn't throw (in effect,
everything is throw()) except just a few calls for which C++ headers
provide extern "C++" overloading to facilitate C++ callbacks. In POSIX,
a whole bunch of standard C library functions DO "throw" due to thread
cancelation. Isn't that funny?
> >
> > >> When and if the C++ standard adds true thread support, that will be,
> > >> by default and in practice, the thread binding for C++; whether the
> > >> underlying thread environment is POSIX, Win32, or something else. This
> > >> is great, as long as it doesn't do or say anything stupid, but it
> > >> still leaves a few loopholes because inevitably people will continue
> > >> to write applications that mix languages. Mixing C and C++ has never
> > >> been a problem; but if the thread model in C++ is radically different,
> > >> it could become a problem.
> >
> > Absolutely agreed. I've said all along that Boost.Threads has to be very
> > aware of what POSIX says. We can not deviate in any way from POSIX that
> > will result in conflicts between the threading systems.
Bill, Boost.Threads shall end up in standard <thread> header. But there
should also be a <cthread> standard header (it should penetrate ISO C as
well; in the form of either <pthread.h> or <cthread.h> header). Now, in
the past, I was thinking of <thread> as "just" an object layer on top of
<cthread> stuff. That was wrong. <cthread> should be fully implementable
using stuff from <thread>. I mean things along the lines of:
typedef std::thread * pthread_t;
extern "C" pthread_t pthread_self() throw() {
return std::thread_self().raw_ptr();
}
typedef thread_specific_ptr<void, __c_TSD_cleanup> * pthread_key_t;
extern "C" int pthread_key_create(pthread_key_t * key,
void ( * dtor)(void *)) throw() {
try {
// can throw "shall fail" stuff only (std::bad_alloc and std::try_again)
*key = new pthread_key_t(__c_TSD_cleanup(dtor));
// "may fail" shall be caught in the std::unexpected() handler
}
catch(...) {
return __translate_exception_to_error_code_using_throw_and_catch();
}
return 0;
}
typedef std::aligned_storage<std::mutex> pthread_mutex_t;
typedef std::aligned_storage<std::mutexattr_t> pthread_mutexattr_t;
extern "C" int pthread_mutex_init(pthread_mutex_t * mutex_storage,
const pthread_mutexattr_t * attr_storage) throw() {
try {
// can throw "shall fail" stuff only
new (mutex_storage->place()) std::mutex(attr_storage->object());
// "may fail" shall be caught in the std::unexpected() handler
}
catch(...) {
return __translate_exception_to_error_code_using_throw_and_catch();
}
return 0;
}
extern "C" int pthread_mutex_destroy(pthread_mutex_t * mutex_storage) throw() {
// destructor with implicit throw()-nothing ES
~mutex_storage->object();
// "may fail" shall be caught in the std::unexpected() handler
return 0;
}
#define PTHREAD_CANCELED std::thread_canceled()
extern "C" void pthread_exit(void * ptr) throw(std::thread_termination_request) {
(ptr == PTHREAD_CANCELED) ? std::thread_cancel() : std::thread_exit(ptr);
}
using stuff from <thread>:
struct thread_canceled {
operator void * () { return &unique; }
static thread_canceled unique;
};
template<typename T>
void thread_exit(T value) {
assert(std::thread_self().can_exit_with<T>());
throw thread_exit_value(value);
}
template<>
void thread_exit(std::thread_canceled) {
thread_cancel();
}
void thread_cancel() {
throw std::thread_cancel_request();
}
or something like that.
> >
> > >> Furthermore, there's a missing piece that
> > >> neither POSIX 1003.1-2001 plus ISO C++ 2005 (or whatever), or even
> > >> 1003.1-2001 plus a hypothetical "1003.C++" will necessarily (or even
> > >> likely) supply -- and that's how the two interoperate.
> >
> > Agreed, but that's the case today when mixing languages. There are a lot
> > of areas which are left unspecified, even when the languages being mixed
> > are C and C++.
C and C++ WILL merge, sooner or later. The separation of C and C++
languages is/was the stupidest thing C++ authors ever did (or allowed
to happen). Well, just look what's going on with respect to GCC/G++
(adding exceptions and C-destructors IS kinda "merging", I believe).
> >
> > >> If C++ or 1003.C++ says that thread::cancel raises an exception, and
> > >> 1003.1 says that pthread_cancel() invokes cleanup handlers, does that
> > >> mean that cancelling a thread with pthread_cancel() will trigger
> > >> catch(...), or even destructors? Well, maybe not. This could more
> > >> easily be solved with a 1003.C++, perhaps, since at least the two
> > >> standards are in a family. Since the C++ standard is unlikely to
> > >> mention POSIX any more than now, it's unlikely to provide any
> > >> guarantees.
> >
> > No gaurantees. But with a C++ definition, one can at least hope that
> > implementations will try and deal with these cross-language binding issues
> > in some reasonable manner.
*You* should do it for "C subset of C++" (incompatibilities and
"restrict"-like extensions of ISO-C aside for a moment). There will
be NO problems with cross-C/C++-language bindings if Boost would come
up with some "reference implementation" (see above) of <cthread>
(i.e. also <pthread.h>) using stuff from the REAL <thread> header.
You did not seem to like to "force" windows user of Boost.Threads to
download pthreads-win32 and use Boost.Threads on top of it. YOU'RE
RIGHT! Pthreads-win32 will be shutdown as soon as you'll deliver a
<cthread> and <pthread.h> beasts implemented using stuff from the
"boosted" <thread>. And, perhaps, then even Microsoft will follow...
delivering a much better implementation of BOTH (including fully
supported cancelation for all C and C++ standard calls meant to throw
std:thread_cancel_request exception).
> > >> Perhaps that would provide an opportunity for a smaller POSIX project,
> > >> though; a PROFILE that would chink the holes where the two walls meet.
> > >> In effect, specifying a "POSIX platform" supporting both threads and
> > >> C++ that simply says "C++ cancellation is the same as POSIX
> > >> cancellation", "POSIX cleanup handlers are logically and semantically
> > >> the same as C++ object destructors", and "POSIX cancellation is
> > >> visible as a C++ exception".
> >
> > Reasonable things for POSIX to do, or at least consider, IMO.
Hardcore POSIX folks don't really "think C++", unfortunately. The only
way to get it done is to deliver POSIX threading API implementation "on
top" of Boost.Threads to them, I think. Well, this would also mean a
whole bunch of extensions to the current POSIX threading -- things like
parameterized pthread_once() and TSD destructors (to support shared_ptr
like "custom deleters" without too much overhead), etcetera.
What do you think?
regards,
alexander.
Alexander Terekhov
Edward Diener wrote:
>
> Alexander Terekhov wrote:
> > Hardcore POSIX folks don't really "think C++", unfortunately. The only
> > way to get it done is to deliver POSIX threading API implementation
> > "on
> > top" of Boost.Threads to them, I think. Well, this would also mean a
> > whole bunch of extensions to the current POSIX threading -- things
> > like parameterized pthread_once() and TSD destructors (to support
> > shared_ptr
> > like "custom deleters" without too much overhead), etcetera.
> >
> > What do you think?
>
> What I think is that it is about time that C++ stop trying to accomodate the
> C programming language in any respect, and develop itself using C++ idioms
> and ideas even if it means leaving the C language completely behind.
I don't understand.
What's the problem with respect to "additional" C interface to the
pure C++ stuff with whatever-C++-"idioms and ideas"-you-like? You
just hate void *, or what? If you hate it, don't use it.
I think that you've missed the point. The "extensions" I was talking
about can be illustrated on thread_specific_ptr (current boost::once
ugliness aside for a moment). As far as I can see, efficient support
[without considerable overhead] for the C++ style deleters needs the
system support for a TSD destructor callback that would allow to have
something along the lines of "dtor" below:
template<typename T, typename cleanup>
class thread_specific_ptr : cleanup /*, noncopyable */ {
...
static void dtor(void * data, void * THIS) {
static_cast<thread_specific_ptr*>(THIS)->operator()(static_cast<T*>(data));
}
...
};
as the TSD destructor. Basically you need the following pthread
"extension"
extern "C++" int pthread_key_create(pthread_key_t *,
void (* dtor)(void *, void *),
void * state) throw();
it doesn't need to be a "pthread" call. The system could provide
extern "C++" int __tsd_key_create(__tsd_key_t *,
void (* dtor)(void *, void *),
void * state) throw();
(or whatever)
and once you have THAT (plus primitive get/set operations), you can
implement a C++ thread_specific_ptr<T, cleanup> template with e.g.:
thread_specific_ptr();
thread_specific_ptr(const cleanup&);
~thread_specific_ptr() throw();
T * get() const throw();
void set(T *) throw(std::bad_alloc);
T * operator->() const throw();
T * release() throw();
void dispose() throw();
void reset(T *) throw(std::bad_alloc);
and layer the entire pthread TSD C-API "on top" of it (with
_release(), _dispose(), and _reset() calls also added as "extensions").
What's the problem?
> This is
> what Boost is currently doing and I see attempts to accomodate C as
> crippling the vitality of C++ and blocking the attempt to create a more
> dynamic C++ language for the future.
regards,
alexander.
Alexander Terekhov
-------- Original Message --------
Message-ID: <3ED4B964...@web.de>
Newsgroups: comp.lang.c++.moderated
Subject: Re: OO design: Is "errno" Exception?
References: ... <vd79jua...@corp.supernews.com>
Early Ehlinger wrote:
>
> "Alexander Terekhov" <tere...@web.de> wrote:
> > Early Ehlinger wrote:
> > [...]
> > > An error is an error is an error.
> >
> > No. "shall fail" POSIX errors are meant to be thrown as exceptions
> > but "may fail" POSIX errors are just *your* (or implementors) BUGS.
>
> Who exactly meant that "shall fail" POSIX errors are to be thrown as
> exceptions? POSIX? I doubt it; unlessed I missed something, POSIX has
> no concept of exceptions.
POSIX (SUS) systems have a concept of thread cancelation and exit.
That's surely an exception in C++ or C-with-exceptions; do a search
on "pthread_cancel_e". ;-)
>
> It seems to me that you haven't really made a distinction. If a "may
> fail" error is indeed a bug, then it should be thrown as an exception
> so that the program containing the bug will fail gloriously :) Why
> would "may fail" be any different than "shall fail" in terms of
>
> > Here's an illustration (BTW, "more on this" can be found in my sig).
>
> I'm not sure how this code illustrates your point... Would you mind
> being more specific?
No problem. Imagine a system interface for TSD access that doesn't
throw anything and just returns "status" info:
typedef void * __TSD_key_t; // whatever
int __tsd_key_create(
__TSD_key_t *
, void (* dtor)(void *, void *), void *
) throw();
int __tsd_key_delete(
__TSD_key_t
) throw();
int __tsd_getspecific(
__TSD_key_t
, void * *
) throw();
int __tsd_setspecific(
__TSD_key_t
, void *
) throw();
Now let's try to develop a <thread>'s thread_specific_ptr<> beast:
namespace std {
struct no_cleanup {
void operator()(void *) {
// NOOP
}
};
template<typename cleanup>
bool no_TSD_cleanup(const cleanup &) throw() {
return false;
}
template<>
bool no_TSD_cleanup(const no_cleanup &) throw() {
return true;
}
template<typename T, typename cleanup>
class thread_specific_ptr : cleanup /* noncopyable */ {
__TSD_key_t __key;
static void dtor(void * data, void * THIS) {
static_cast<thread_specific_ptr*>(THIS)->
operator()(static_cast<T*>(data));
}
public:
thread_specific_ptr()
throw(std::bad_alloc, std::try_again);
thread_specific_ptr(const cleanup&)
throw(std::bad_alloc, std::try_again);
~thread_specific_ptr() throw();
T * get() throw();
void set(T *) throw(std::bad_alloc);
T * operator->() throw();
T * release() throw();
void dispose() throw();
void reset(T *) throw(std::bad_alloc);
};
}
Now, here's its possible implementation:
namespace std {
void throw_errno_exception(int error) { /* ... */ }
template<typename T, typename cleanup>
thread_specific_ptr<T, cleanup>::thread_specific_ptr()
throw(std::bad_alloc, std::try_again) {
int status = __tsd_key_create(&__key, no_TSD_cleanup(
*static_cast<cleanup*> (this)) ? 0 : &dtor, this);
if (status) throw_errno_exception(status);
}
template<typename T, typename cleanup>
thread_specific_ptr<T, cleanup>::thread_specific_ptr(
const cleanup& __cleanup) throw(std::bad_alloc,
std::try_again) : cleanup(__cleanup) {
int status = __tsd_key_create(&__key, no_TSD_cleanup(
__cleanup) ? 0 : &dtor, this);
if (status) throw_errno_exception(status);
}
template<typename T, typename cleanup>
thread_specific_ptr<T, cleanup>::~thread_specific_ptr()
throw() {
int status = __tsd_key_delete(__key);
if (status) throw_errno_exception(status);
}
template<typename T, typename cleanup>
T * thread_specific_ptr<T, cleanup>::get() throw() {
void * p;
int status = __tsd_getspecific(__key, &p);
if (status) throw_errno_exception(status);
return p;
}
template<typename T, typename cleanup>
void thread_specific_ptr<T, cleanup>::set(T* p)
throw(std::bad_alloc) {
int status = __tsd_setspecific(__key, p);
if (status) throw_errno_exception(status);
}
template<typename T, typename cleanup>
T * thread_specific_ptr<T, cleanup>::release() throw() {
void * p = get();
set(0);
return p;
}
template<typename T, typename cleanup>
void thread_specific_ptr<T, cleanup>::dispose() throw() {
this->cleanup::operator()(release());
}
template<typename T, typename cleanup>
void thread_specific_ptr<T, cleanup>::reset(T* p)
throw(std::bad_alloc) {
void * old_p = get();
if (old_p != p) {
set(p);
this->cleanup::operator()(old_p);
}
}
}
Now, the only thing that's still missing is a <cthread> layer...
Here we go:
// Possible implementation for <cthread>
#include <thread>
namespace std {
extern "C" typedef void (* __c_TSD_dtor_t)(void *);
extern "C++" typedef void (* __cpp_TSD_dtor_t)(void *);
struct __cthread_TSD_cleanup {
__cthread_TSD_cleanup(__c_TSD_dtor_t __c_TSD_dtor_) :
__func(__c_TSD_dtor_ ? c : null),
__c_TSD_dtor(__c_TSD_dtor_) {
}
__cthread_TSD_cleanup(__cpp_TSD_dtor_t __cpp_TSD_dtor_) :
__func(__cpp_TSD_dtor_ ? cpp : null),
__cpp_TSD_dtor(__cpp_TSD_dtor_) {
}
void operator()(void * __data) {
if (__data) switch(__func) {
case c: __c_TSD_dtor(__data); break;
case cpp: __cpp_TSD_dtor(__data); break;
}
}
enum { null, c, cpp } __func;
union {
__c_TSD_dtor_t __c_TSD_dtor;
__cpp_TSD_dtor_t __cpp_TSD_dtor;
};
};
template<>
bool no_TSD_cleanup(const __cthread_TSD_cleanup & __cleanup)
throw() {
return __cleanup.__func == __cthread_TSD_cleanup::null;
}
typedef std::thread_specific_ptr<void, __cthread_TSD_cleanup> *
pthread_key_t;
// try { throw; } catch... "idiom"
int __translate_exception_to_error_code() throw();
extern "C" int pthread_key_create(pthread_key_t * key,
void ( * dtor)(void *)) throw() {
try {
// can throw "shall fail" stuff only (std::bad_alloc and
// std::try_again)
*key = new std::thread_specific_ptr<void,
__cthread_TSD_cleanup>(__cthread_TSD_cleanup(dtor));
// "may fail" shall be caught in the std::unexpected() handler
// for details... please click here: <http://tinyurl.com/cu9k>
}
catch(...) {
return __translate_exception_to_error_code();
}
return 0;
}
extern "C++" int pthread_key_create(pthread_key_t * key,
void ( * dtor)(void *)) throw() {
try {
// can throw "shall fail" stuff only (std::bad_alloc and
// std::try_again)
*key = new std::thread_specific_ptr<void,
__cthread_TSD_cleanup>(__cthread_TSD_cleanup(dtor));
// "may fail" shall be caught in the std::unexpected() handler
// for details... please click here: <http://tinyurl.com/cu9k>
}
catch(...) {
return __translate_exception_to_error_code();
}
return 0;
}
extern "C" int pthread_key_delete(pthread_key_t key) throw() {
// "may fail" shall be caught in the std::unexpected() handler
// for details... please click here: <http://tinyurl.com/cu9k>
delete key;
return 0;
}
extern "C" void * pthread_getspecific(pthread_key_t key) throw() {
// "may fail" shall be caught in the std::unexpected() handler
// for details... please click here: <http://tinyurl.com/cu9k>
return key->get();
}
extern "C" int pthread_setspecific(pthread_key_t key,
const void * p) throw(std::bad_alloc) {
try {
// can throw "shall fail" stuff only (std::bad_alloc)
key->set(const_cast<void *>(p));
// "may fail" shall be caught in the std::unexpected() handler
// for details... please click here: <http://tinyurl.com/cu9k>
}
catch(...) {
return __translate_exception_to_error_code();
}
return 0;
}
extern "C" int pthread_resetspecific(pthread_key_t key,
const void * p) throw(std::bad_alloc) {
try {
// can throw "shall fail" stuff only (std::bad_alloc)
key->reset(const_cast<void *>(p));
// "may fail" shall be caught in the std::unexpected() handler
// for details... please click here: <http://tinyurl.com/cu9k>
}
catch(...) {
return __translate_exception_to_error_code();
}
return 0;
}
extern "C" void * pthread_releasespecific(pthread_key_t key) throw() {
// "may fail" shall be caught in the std::unexpected() handler
// for details... please click here: <http://tinyurl.com/cu9k>
return key->release();
}
extern "C" void pthread_disposespecific(pthread_key_t key) throw() {
// "may fail" shall be caught in the std::unexpected() handler
// for details... please click here: <http://tinyurl.com/cu9k>
return key->dispose();
}
}
("or something like that")
Do you understand it now? ;-)
>
> > T * release() throw() {
> > T * p = get();
> > if (p) set(0); // only an idiot will throw std::bad_alloc here
> > return p;
> > }
>
> At the risk of being an idiot, I'm going to beg to differ.
>
> set() uses pthread_setspecific, which only fails with [ENOMEM] when
> insufficient memory exists to associate the value with the key (at
> least according to opengroup.org).
>
> So you're saying that if set(0) fails, then it's ok to just ignore
> the error? If release() is meant to release ownership (in the same
> sense that auto_ptr<>::release() releases ownership) then this is a
> terrible thing to do. What you will be left with is two entities,
> "this" and "the caller", that both think they exclusively own "T*"!!!
> This is absolutely horrid and the epitomy of pure evil.
Please follow the links:
http://lists.boost.org/MailArchives/boost/msg47702.php
(Subject: [boost] Re: thread lib: thread specific storage problem)
Thank you.
regards,
alexander.
--
"// Possible implementation for <pthread.h> and <cthread>
#include <thread>
// for <cthread>, please remove the using-directive
using namespace std;"
-- "alt"
Alexander Terekhov
From: "William E. Kempf" <wek...@cox.net>
Newsgroups: gmane.comp.lib.boost.devel
Subject: Re: Re: Upcoming ISO/IEC <thread>... and <pthread.h> -> <cthread> transition ;-)
Date: Mon, 2 Jun 2003 11:34:24 -0500 (CDT)
Sender: boost-...@lists.boost.org
"William E. Kempf" wrote:
>
> Alexander Terekhov said:
>
> Sorry for the late reply. I've been on vacation and away from 'net access
> for a week. Still catching up on a LOT of e-mail, so I'm sure there's
> been a lot of responses to this from others already, and I have not read
> them yet. So bear with me.
>
> > Alexander Terekhov wrote:
> >>
> >> "William E. Kempf" wrote:
> >> [...]
> >> > >> How about moving this discussion to c.p.t.?
> >> > >
> >> > > Well, just in case... <Forward Quoted>
> >> >
> >> > Thanks... I currently can't access c.p.t. in any reasonable manner.
> >> I'm working to rectify this,
> >>
> >> http://news.cis.dfn.de might help. ;-)
> >>
> >> but in the mean time, I appreciate the
> >> cross
> >> > post.
> >>
> >> I'll wait a day or two and post a reply addressing some of your points
> >> to comp.programming.threads.
> >
> > "just in case..." <Forward Inline>
> >
> > Alexander Terekhov wrote:
> >>
> >> <Forward-Quoted source=Boost>
> >>
> >> "William E. Kempf" wrote:
> > [...]
> >> > >> The big hurdle for a true C++ binding is that the current state
> >> of affairs is "good enough" for most people, and the political
> >> process of developing a full native C++ binding would be painful.
> >> (Remember, it's not just saying that the thread::create method
> >> takes a class member at which the thread will start... it means
> >> reviewing every method and template in the STL to determine which
> >> have thread safety
> >> > >> requirements, and deciding precisely what those requirements are
> >> and how to meet them. Then there's the matter of cancellation
> >> points... and so forth.)
> >> >
> >> > Most STL libraries are thread-safe today, so the analysis there
> >> wouldn't be too difficult.
> >
> > Well, <http://lists.boost.org/MailArchives/boost/msg47701.php>.
>
> Yes. I didn't mean to indicate there was *no* evaluation to be done.
> Only that the lion's share has already been done by library implementers
> today.
>
> >> > It just needs to be stated explicitly in the
> >> standard.
> >> > Cancellation points are another issue... but I don't think C++ will
> >> add too many to the list already provided by POSIX.
> >
> > The current C++ Std is in conflict with POSIX, to begin with.
>
> Not exactly. POSIX specifies C language extension libraries. As such,
> there is no relationship to C++ at all. They're not part of the C
> standard, so C++ doesn't address them, while POSIX doesn't address
> bindings for any language but C. So the "conflict" is that they are
> simply unrelated. If POSIX were to submit their libraries for inclusion
> in the C standard, then things would be a little different. However, the
> C++ standard does not gaurantee that it will track the C standard's future
> changes. In fact, there are incompatibilities with C99 already. There is
> incentive to do so (for instance, they are discussing how to integrate the
> C99 changes), but since they are seperate standards this may not always be
> possible.
>
> > The C++
> > standard says that almost the entire C library doesn't throw (in effect,
> > everything is throw()) except just a few calls for which C++ headers
> > provide extern "C++" overloading to facilitate C++ callbacks. In POSIX,
> > a whole bunch of standard C library functions DO "throw" due to thread
> > cancelation. Isn't that funny?
>
> Not really funny. But POSIX doesn't specify that cancellation results in
> a C++ exception being thrown either. So there's no technical conflict
> here, even if there's all sorts of headaches for users. I hope this
> improves from our efforts, but there's no gaurantee, since, again, they
> are seperate and unrelated standards. In the mean time, this results in a
> QOI issue.
>
> >> > >> When and if the C++ standard adds true thread support, that will
> >> be, by default and in practice, the thread binding for C++;
> >> whether the underlying thread environment is POSIX, Win32, or
> >> something else. This is great, as long as it doesn't do or say
> >> anything stupid, but it still leaves a few loopholes because
> >> inevitably people will continue to write applications that mix
> >> languages. Mixing C and C++ has never been a problem; but if the
> >> thread model in C++ is radically different, it could become a
> >> problem.
> >> >
> >> > Absolutely agreed. I've said all along that Boost.Threads has to be
> >> very aware of what POSIX says. We can not deviate in any way from
> >> POSIX that will result in conflicts between the threading systems.
> >
> > Bill, Boost.Threads shall end up in standard <thread> header. But there
> > should also be a <cthread> standard header (it should penetrate ISO C as
> > well; in the form of either <pthread.h> or <cthread.h> header). Now, in
> > the past, I was thinking of <thread> as "just" an object layer on top
> > of <cthread> stuff. That was wrong. <cthread> should be fully
> > implementable using stuff from <thread>. I mean things along the lines
> > of:
>
> I see no reason for C++ to include a <cthread>, unless it's there for
> compatibility with a C <thread.h>. IOW, POSIX should address the C
> standard first, not the other way around. (And not all of POSIX is
> necessarily appropriate, either, as the impact to non-POSIX platforms can
> be quite extensive and you are likely to find opposition from those
> members.)
> Give me a valid reason for having a C style interface and I'll certainly
> consider adding it to Boost.Threads and recommending it to the committee.
> But I don't see a need for it myself.
>
> >> > >> Furthermore, there's a missing piece that
> >> > >> neither POSIX 1003.1-2001 plus ISO C++ 2005 (or whatever), or
> >> even 1003.1-2001 plus a hypothetical "1003.C++" will necessarily
> >> (or even likely) supply -- and that's how the two interoperate.
> >> >
> >> > Agreed, but that's the case today when mixing languages. There are
> >> a lot of areas which are left unspecified, even when the languages
> >> being mixed are C and C++.
> >
> > C and C++ WILL merge, sooner or later. The separation of C and C++
> > languages is/was the stupidest thing C++ authors ever did (or allowed
> > to happen). Well, just look what's going on with respect to GCC/G++
> > (adding exceptions and C-destructors IS kinda "merging", I believe).
>
> Strong words (you did the shouting), with no indication this is so from
> any of the people who would dictate this. Or did I miss something? I'm
> not at all sure it make sense for C and C++ to merge. But if it ever
> does, they will address those problems then. I don't see much that I can
> do today to help in this regard.
>
> >> > >> If C++ or 1003.C++ says that thread::cancel raises an exception,
> >> and 1003.1 says that pthread_cancel() invokes cleanup handlers,
> >> does that mean that cancelling a thread with pthread_cancel()
> >> will trigger catch(...), or even destructors? Well, maybe not.
> >> This could more easily be solved with a 1003.C++, perhaps, since
> >> at least the two standards are in a family. Since the C++
> >> standard is unlikely to mention POSIX any more than now, it's
> >> unlikely to provide any guarantees.
> >> >
> >> > No gaurantees. But with a C++ definition, one can at least hope
> >> that implementations will try and deal with these cross-language
> >> binding issues in some reasonable manner.
> >
> > *You* should do it for "C subset of C++" (incompatibilities and
> > "restrict"-like extensions of ISO-C aside for a moment). There will be
> > NO problems with cross-C/C++-language bindings if Boost would come up
> > with some "reference implementation" (see above) of <cthread>
> > (i.e. also <pthread.h>) using stuff from the REAL <thread> header.
>
> There is no "C subset of C++" that addresses threading. Again, if you
> want that, address the C standard first.
>
> > You did not seem to like to "force" windows user of Boost.Threads to
> > download pthreads-win32 and use Boost.Threads on top of it. YOU'RE
> > RIGHT! Pthreads-win32 will be shutdown as soon as you'll deliver a
> > <cthread> and <pthread.h> beasts implemented using stuff from the
> > "boosted" <thread>. And, perhaps, then even Microsoft will follow...
> > delivering a much better implementation of BOTH (including fully
> > supported cancelation for all C and C++ standard calls meant to throw
> > std:thread_cancel_request exception).
>
> Interesting thought, but you've not supplied a reason for me to be
> interested in a C binding. And if I were, I'm not sure how the
> implementation would be factored... the layering approach will add
> overhead that may or may not be important.
>
> >> > >> Perhaps that would provide an opportunity for a smaller POSIX
> >> project, though; a PROFILE that would chink the holes where the
> >> two walls meet. In effect, specifying a "POSIX platform"
> >> supporting both threads and C++ that simply says "C++
> >> cancellation is the same as POSIX cancellation", "POSIX cleanup
> >> handlers are logically and semantically the same as C++ object
> >> destructors", and "POSIX cancellation is visible as a C++
> >> exception".
> >> >
> >> > Reasonable things for POSIX to do, or at least consider, IMO.
> >
> > Hardcore POSIX folks don't really "think C++", unfortunately. The only
> > way to get it done is to deliver POSIX threading API implementation "on
> > top" of Boost.Threads to them, I think. Well, this would also mean a
> > whole bunch of extensions to the current POSIX threading -- things like
> > parameterized pthread_once() and TSD destructors (to support shared_ptr
> > like "custom deleters" without too much overhead), etcetera.
> >
> > What do you think?
>
> I understand your motivations. There's a lot to be said to get all of the
> players (C/C++/POSIX) intimately involved with each other. But I think
> you're suggesting going about it wrong. First, POSIX should be added to
> the C standard (or portions of it, if that's what the committee members
> deem appropriate). Then we can try and address the C/C++ boundary
> issues... if possible. I'm not sure you'll ever be able to address all of
> them, since they ARE sperate languages, beyond a QOI issue.
>
> --
> William E. Kempf
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Alexander Terekhov
-------- Original Message --------
Message-ID: <3EDC70EE...@web.de>
Newsgroups: gmane.comp.lib.boost.devel
"William E. Kempf" wrote:
[...]
> >> > >> When and if the C++ standard adds true thread support, that will
> >> be, by default and in practice, the thread binding for C++;
> >> whether the underlying thread environment is POSIX, Win32, or
> >> something else. This is great, as long as it doesn't do or say
> >> anything stupid, but it still leaves a few loopholes because
> >> inevitably people will continue to write applications that mix
> >> languages. Mixing C and C++ has never been a problem; but if the
> >> thread model in C++ is radically different, it could become a
> >> problem.
> >> >
> >> > Absolutely agreed. I've said all along that Boost.Threads has to be
> >> very aware of what POSIX says. We can not deviate in any way from
> >> POSIX that will result in conflicts between the threading systems.
> >
> > Bill, Boost.Threads shall end up in standard <thread> header. But there
> > should also be a <cthread> standard header (it should penetrate ISO C as
> > well; in the form of either <pthread.h> or <cthread.h> header). Now, in
> > the past, I was thinking of <thread> as "just" an object layer on top
> > of <cthread> stuff. That was wrong. <cthread> should be fully
> > implementable using stuff from <thread>. I mean things along the lines
> > of:
>
> I see no reason for C++ to include a <cthread>, unless it's there for
> compatibility with a C <thread.h>.
The compatibility issue here is not <thread.h> but rather <pthread.h>.
> IOW, POSIX should address the C
> standard first, not the other way around. (And not all of POSIX is
> necessarily appropriate, either, as the impact to non-POSIX platforms can
> be quite extensive and you are likely to find opposition from those
> members.)
I'd love to hear something from them. MS-folks, are you here? Y'know,
I guess that NOW, given Microsoft's recent acquisition of "The UNIX
license" from The SCO (aka "hey-IBM-give-me-a-billion") Group, they
will have NO problems whatsoever merging win32 and Interix/POSIX sub
systems... http://google.com/groups?selm=3DE4FF8C.FA94CDAC%40web.de
[...typedef std::aligned_storage<std::mutex> pthread_mutex_t;...]
I've recently found&corrected a typo in that snippet. Here's what
I wrote recently: (I hope it's relevant to this discussion as well)
:David Schwartz wrote:
:>
:> "Wil Evers" <bou...@dev.null> wrote in message
:> news:3ed83fe8$0$2232$e4fe...@dreader6.news.xs4all.nl...
:>
:> > Not sure I agree. Assuming no special 'compiler magic' is used, and the
:> > definitions of pthread_mutex_t and PTHREAD_MUTEX_INITIALIZER are shared
:> > between C and C++, then pthread_mutex_t must be a POD and
:> > PTHREAD_MUTEX_INITIALIZER must be a constant expression,
:
:Yeah. http://google.com/groups?selm=3ED1E663.B9C89A4F%40web.de
:
:"typedef std::aligned_storage<std::mutex> pthread_mutex_t;"
:
:This is meant to be a properly aligned POD; e.g. POD-union with
:a character array [or whatever] meant to be const-initialized by
:the <cthread>'s PTHREAD_MUTEX_INITIALIZER. BTW, I've made a typo:
:
:"extern "C" int pthread_mutex_destroy(pthread_mutex_t * mutex_storage)
: throw() {
: // destructor with implicit throw()-nothing ES
: ~mutex_storage->object();
: // "may fail" shall be caught in the std::unexpected() handler
: return 0;
: }"
:
:actually meant to be:
:
: extern "C" int pthread_mutex_destroy(pthread_mutex_t * mutex_storage)
: throw() {
: // destructor with implicit throw()-nothing ES
: mutex_storage->object().~mutex();
: // "may fail" shall be caught in the std::unexpected() handler
: return 0;
: }
:
:well, but...
:
:> so the C++ rules
:> > for dynamic initialization do not apply here.
:
:...see below. ;-)
:
:>
:> You are implicitly assuming that the pthreads implementation must
:> strictly conform to the ANSI C standard. Since this is impossible, you
:> should stop assuming it. ;)
:>
:> Why can't PTHREAD_MUTEX_INITIALIZER call a function that isn't
:> reentrant? I mean why can't it be:
:>
:> #define PTHREAD_MUTEX_INITIALIZER get_mutex();
:> #define pthread_mutex_t int;
:> static int next_mutex=0;
:> int get_mutex(void) { return next_mutex++; }
:
:Yeah, something like that; POSIX.1 doesn't really need to care about
:C++ dynamic init of whatever statics (local or non-local ones). Only
:POSIX.1++ and/or upcoming threaded C++ Std with <cthread> could and
:should sort of "clarify" that. Oder?
Now I'd like to add one more <cthread>'s call:
extern "C++" std::mutex & pthread_mutex(pthread_mutex_t * mutex_storage)
throw() {
return mutex_storage->object();
}
The idea is that you could use <cthread>'s initializers for mutex,
CV, whatever POD "storage objects" of static storage duration and
simply "retrieve" a C++ object reference from it for things like
scoped locking guards and etc.
Well, I'm not sure about
std::pthread_mutex_t& std::mutex::c_mutex() throw();
but the *thread object* class should provide
std::pthread_t std::thread::c_thread() throw();
I believe.
> Give me a valid reason for having a C style interface and I'll certainly
> consider adding it to Boost.Threads and recommending it to the committee.
Just show them this document:
http://std.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1457.pdf
And point "curious folks" to the bits like this:
"....
Obviously, interface definitions written in the common subset
of C and C++ would have the widest potential audience, since
they would be readable by compilers for both languages. But
the additional abstraction mechanisms of C++, such as classes
and templates, are useful in writing code at the hardware
access layer. They allow the encapsulation of features into
classes, providing type safety along with maximum efficiency
through the use of templates.
Nevertheless, it is an important goal to provide an interface
that allows device driver implementers to write code that
compiles equally under C and C++ compilers. Therefore, this
report specifies two interfaces: one using the common subset
of C and C++ and a second using modern C++ constructs.
Implementers of the commonsubset style interface might use
functions or inline functions, or might decide that function-
like macros or intrinsic functions better serve their
objectives.
...."
> But I don't see a need for it myself.
>
> >> > >> Furthermore, there's a missing piece that
> >> > >> neither POSIX 1003.1-2001 plus ISO C++ 2005 (or whatever), or
> >> even 1003.1-2001 plus a hypothetical "1003.C++" will necessarily
> >> (or even likely) supply -- and that's how the two interoperate.
> >> >
> >> > Agreed, but that's the case today when mixing languages. There are
> >> a lot of areas which are left unspecified, even when the languages
> >> being mixed are C and C++.
> >
> > C and C++ WILL merge, sooner or later. The separation of C and C++
> > languages is/was the stupidest thing C++ authors ever did (or allowed
> > to happen). Well, just look what's going on with respect to GCC/G++
> > (adding exceptions and C-destructors IS kinda "merging", I believe).
>
> Strong words (you did the shouting), with no indication this is so from
> any of the people who would dictate this. Or did I miss something?
Well, try <http://www.research.att.com/~bs/papers.html>, to begin with.
regards,
alexander.
Alexander Terekhov
"William E. Kempf" wrote:
>
> Alexander Terekhov said:
> Which is a POSIX header, not a C or C++ header. I'm not going to suggest
> that the C++ language standard be made compatible with POSIX, nor do I
> think you'd be able to convince the committee of this if *you* were to
> suggest it.
>
> >> IOW, POSIX should address the C
> >> standard first, not the other way around. (And not all of POSIX is
> >> necessarily appropriate, either, as the impact to non-POSIX platforms
> >> can be quite extensive and you are likely to find opposition from
> >> those members.)
> >
> > I'd love to hear something from them. MS-folks, are you here? Y'know, I
> > guess that NOW, given Microsoft's recent acquisition of "The UNIX
> > license" from The SCO (aka "hey-IBM-give-me-a-billion") Group, they
> > will have NO problems whatsoever merging win32 and Interix/POSIX sub
> > systems... http://google.com/groups?selm=3DE4FF8C.FA94CDAC%40web.de
>
> I wasn't specifically meaning MS. After all, the Windows platform is
> already at least partially POSIX. There are other, non-POSIX platforms,
> however.
>
> But I'm sure MS would have issues with adopting all of POSIX if you were
> to suggest it. There are certain areas which are incompatible, such as
> path naming, which would be problematic at best to be switched over to a
> POSIX compatible form. And this one even rears its ugly head in pthreads
> (indirectly) where shared memory is created with path names.
>
> > [...typedef std::aligned_storage<std::mutex> pthread_mutex_t;...]
> >
> > I've recently found&corrected a typo in that snippet. Here's what
> > I wrote recently: (I hope it's relevant to this discussion as well)
>
> I'm lost. I never referenced what you are talking about here. I'll have
> to spend some time reading all of this thread (including your links) to
> get back on track. A better job of quoting would save both of us some
> time here.
> I follow what's said here, but can't figure out what you want me to pay
> attention to.
>
> > Now I'd like to add one more <cthread>'s call:
> >
> > extern "C++" std::mutex & pthread_mutex(pthread_mutex_t * mutex_storage)
> >
> > throw() {
> > return mutex_storage->object();
> > }
> >
> > The idea is that you could use <cthread>'s initializers for mutex, CV,
> > whatever POD "storage objects" of static storage duration and simply
> > "retrieve" a C++ object reference from it for things like
> > scoped locking guards and etc.
> >
> > Well, I'm not sure about
> >
> > std::pthread_mutex_t& std::mutex::c_mutex() throw();
> >
> > but the *thread object* class should provide
> >
> > std::pthread_t std::thread::c_thread() throw();
> >
> > I believe.
>
> You've got some interesting ideas for merging POSIX and C++. But, I'm
> sorry, I just can't get on board here. Providing a POSIX C++ binding
> would require actual language changes, would probably force non-POSIX
> platforms to make some significant changes which could be prohibitive
> (though the pthreads library alone doesn't have too much specified that
> would obviously cause such problems), and I think would be a very hard
> sell.
> Quoted out of context. In context, this is about hardware I/O support.
> Completely different subject matter, and I'm not at all sure that what's
> said above applies to *this* context.
>
> >> But I don't see a need for it myself.
> >>
> >> >> > >> Furthermore, there's a missing piece that
> >> >> > >> neither POSIX 1003.1-2001 plus ISO C++ 2005 (or whatever), or
> >> >> even 1003.1-2001 plus a hypothetical "1003.C++" will necessarily
> >> (or even likely) supply -- and that's how the two interoperate.
> >> >> >
> >> >> > Agreed, but that's the case today when mixing languages. There
> >> are
> >> >> a lot of areas which are left unspecified, even when the languages
> >> being mixed are C and C++.
> >> >
> >> > C and C++ WILL merge, sooner or later. The separation of C and C++
> >> languages is/was the stupidest thing C++ authors ever did (or
> >> allowed to happen). Well, just look what's going on with respect to
> >> GCC/G++ (adding exceptions and C-destructors IS kinda "merging", I
> >> believe).
> >>
> >> Strong words (you did the shouting), with no indication this is so
> >> from any of the people who would dictate this. Or did I miss
> >> something?
> >
> > Well, try <http://www.research.att.com/~bs/papers.html>, to begin with.
>
> I'm aware of most of these papers already. They don't indicate any plans
> to merge C and C++, that I can see. He discusses syntax compatibility,
> not binary compatibility. I may be wrong, but I don't think either
> commitee wants to specify an ABI, and with out doing that, I'm not sure
> how you can mandate compatibility between compilers, much less languages.