commoncpp vs pthread (was: c++ with pthread?)

Nicolas Blais nb_root at
Sat Nov 26 15:58:48 GMT 2005

I finaly converted one of my c++ threading app from pthread alone to 
commoncpp.  I've subjectively compared the 'before' and 'after' to see which 
was more advantageous for me (as in good 'ol pthread or commoncpp library). 

The result is a disappointment.

With commoncpp:
1. Poorly documented. -> 
(yes it's a 404)

2. Thread::getThreadId(void) exists in the documentation, but does not 
appently exists in cc++/thread.h, so a call to it fails build.  
getPthreadId(void) is there.

3. SIGSEGV when calling delete->this in a thread's destructor.  In fact, 
commoncpp will SIGSEGV it's own simple test program, thread2.cpp.  (gdb: 
death @ ost::Thread::close ()).  A bug report was sent to the developper 2 
weeks ago.  Whether this is a FreeBSD problem or a commoncpp problem is 

4. From what I understand, Thread::join will unblock when a thread correctly 
exits and clean, which will never happen because of #3.  My app relies on 
threads joining.  From experience, if I remove delete->this from my thread's 
Final() call, the thread will never unblock and the app forever waits.  If I 
leave delete->this (as recommended by the docs), it will SIGSEGV.

5. Coding with commoncpp is actual more simple that directly using -lpthread.  

So I went back to faithful -lpthread with my C++ apps.  I believe commoncpp 
can be a good threading library, but it is currently not at that state yet. I 
haven't tested the many other features of commoncpp.

FreeBSD 7.0-CURRENT #1: Sat Nov 19 12:36:29 EST 2005     
root at clk01a:/usr/obj/usr/src/sys/CLK01A 
PGP? (updated 16 Nov 05) :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the freebsd-threads mailing list