Date: Tue, 08 Nov 2005 05:54:43 -0500 From: Nicolas Blais <nb_root@videotron.ca> To: freebsd-threads@freebsd.org Cc: Norbert Koch <NKoch@demig.de> Subject: Re: c++ with pthread? Message-ID: <200511080554.48373.nb_root@videotron.ca> In-Reply-To: <000701c5e432$fb600980$4801a8c0@ws-ew-3.demig.intra> References: <000701c5e432$fb600980$4801a8c0@ws-ew-3.demig.intra>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] > Commoncpp tries to be platform-independent. So, no. > What performance are you talking about? Thread creation > may be slower, but context changes are always handled by > pthread. So there would be no difference. > Mutexes and conditionals will be slower too. > I never ran any benchmarks. Actually, I've run into a decision forcing event with commoncpp. It segfaults one of it's own very simple test code (thread2.cpp) : http://www.gnu.org/software/commoncpp/docs/refman/html/thread2_8cpp-example.html Either it's me, FreeBSD or the actual librairie that cause the segfault. I've even 'sent-pr' to update the port to the last version and it causes the same segfault. gdb gives: Starting program: /home/nicblais/test/cc/a.out (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...warning: Unable to get location for thread creation breakpoint: generic error [New LWP 100180] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...starting father thread starting child thread child start father end child end [New Thread 0x8057600 (LWP 100180)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x8057600 (LWP 100180)] 0x280d4c95 in ost::Thread::close () from /usr/local/lib/libccgnu2-1.3.so.1 from thread2.cpp compile like so: gcc -I/usr/local/include/cc++2 -D_THREAD_SAFE -D_GNU_SOURCE -I/usr/local/include -L/usr/local/lib -lccext2 -lccgnu2 -L/usr/local/lib -lxml2 -lz -L/usr/local/lib -liconv -lm -lz -pthread thread2.cpp Since the actual fault is in libccgnu2, I've submitted a bug report on sourceforge. Sadly enough, this situation has cause me to stay with pthread so far. About ptmalloc2, is the reason it wasn't implemented a compatibility issue? Licensing maybe? Technical? Nicolas. -- FreeBSD 7.0-CURRENT #0: Sat Nov 5 12:12:36 EST 2005 root@clk01a:/usr/obj/usr/src/sys/CLK01A PGP? : http://www.clkroot.net/security/nb_root.asc [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDcIP4z38ton5LGeIRAmpcAKCCS26KPGmPxRKrLJuknpxRPYdCgACgl6ou FESQGSg6PrWMmXbp2F1+i8w= =bcZs -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511080554.48373.nb_root>