[threads] namespace & externs
Boosters, In boost/thread/src/pthread/thread.cpp we see extern "C" {} around code such as tls_destructor. Is this needed so it interfaces w/ native pthread local storage? When a vendor program is built against a specific version of boost it usually becomes necessary to isolate other users via a namespace. However, anything with extern "C" style defeats this. Aside from explicit linking to native c api's are there reasons for this; also what's considered the best style to isolate different versions -- currently we modify every header with a version-ed namespace wrapper. thanks! -s-
scot shinderman <scot@imageworks.com> writes:
In boost/thread/src/pthread/thread.cpp we see extern "C" {} around code such as tls_destructor. Is this needed so it interfaces w/ native pthread local storage?
Yes.
When a vendor program is built against a specific version of boost it usually becomes necessary to isolate other users via a namespace. However, anything with extern "C" style defeats this. Aside from explicit linking to native c api's are there reasons for this; also what's considered the best style to isolate different versions -- currently we modify every header with a version-ed namespace wrapper.
extern "C" is only used where it is necessary (at least, that is the intent). If you need the extern "C" stuff to be versioned then you'll have to rename it. Renaming the namespace seems a sensible option for the rest of the code. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Anthony Williams <anthony.ajw <at> gmail.com> writes:
scot shinderman <scot <at> imageworks.com> writes:
In boost/thread/src/pthread/thread.cpp we see extern "C" {} around code such as tls_destructor. Is this needed so it interfaces w/ native pthread local storage?
Yes.
When a vendor program is built against a specific version of boost it usually becomes necessary to isolate other users via a namespace. However, anything with extern "C" style defeats this. Aside from explicit linking to native c api's are there reasons for this; also what's considered the best style to isolate different versions -- currently we modify every header with a version-ed namespace wrapper.
extern "C" is only used where it is necessary (at least, that is the intent). If you need the extern "C" stuff to be versioned then you'll have to rename it. Renaming the namespace seems a sensible option for the rest of the code.
A little confused by this last part -- if the routine tls_destructor can be renamed something i.e. tls_destructor_v2 then why does it need to be extern "C" at all (why wouldn't the name-mangled version work as well)? If the pthread library cannot find something called tls_destructor what will occur? So far in small tests we haven't seen problems; with our vendor's version of boost however thrown into the mix something stills seems awry especially during thread tear down... thanks!
Anthony
Scot Shinderman <scot@imageworks.com> writes:
Anthony Williams <anthony.ajw <at> gmail.com> writes:
scot shinderman <scot <at> imageworks.com> writes:
In boost/thread/src/pthread/thread.cpp we see extern "C" {} around code such as tls_destructor. Is this needed so it interfaces w/ native pthread local storage?
Yes.
When a vendor program is built against a specific version of boost it usually becomes necessary to isolate other users via a namespace. However, anything with extern "C" style defeats this. Aside from explicit linking to native c api's are there reasons for this; also what's considered the best style to isolate different versions -- currently we modify every header with a version-ed namespace wrapper.
extern "C" is only used where it is necessary (at least, that is the intent). If you need the extern "C" stuff to be versioned then you'll have to rename it. Renaming the namespace seems a sensible option for the rest of the code.
A little confused by this last part -- if the routine tls_destructor can be renamed something i.e. tls_destructor_v2 then why does it need to be extern "C" at all (why wouldn't the name-mangled version work as well)? If the pthread library cannot find something called tls_destructor what will occur? So far in small tests we haven't seen problems; with our vendor's version of boost however thrown into the mix something stills seems awry especially during thread tear down...
In this case, extern "C" is not used for the name mangling, but for the calling convention. pthread_key_create requires a pointer to an extern "C" function for the destructor function. Passing a pointer to a normal C++ function is not guaranteed to be portable. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
participants (3)
-
Anthony Williams -
scot shinderman -
Scot Shinderman