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>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart5418983.vW4Y3AATdm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > 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 segfaul= ts=20 one of it's own very simple test code (thread2.cpp) : http://www.gnu.org/software/commoncpp/docs/refman/html/thread2_8cpp-example= =2Ehtml Either it's me, FreeBSD or the actual librairie that cause the segfault. I'= ve=20 even 'sent-pr' to update the port to the last version and it causes the sam= e=20 segfault. gdb gives: Starting program: /home/nicblais/test/cc/a.out (no debugging symbols found)...(no debugging symbols found)...(no debugging= =20 symbols found)...(no debugging symbols found)...(no debugging symbols=20 found)...(no debugging symbols found)...(no debugging symbols=20 found)...warning: Unable to get location for thread creation breakpoint:=20 generic error [New LWP 100180] (no debugging symbols found)...(no debugging symbols found)...(no debugging= =20 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=20 =2DI/usr/local/include -L/usr/local/lib -lccext2 -lccgnu2 -L/usr/local/lib= =20 =2Dlxml2 -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=20 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= ?=20 Licensing maybe? Technical? Nicolas. =2D-=20 =46reeBSD 7.0-CURRENT #0: Sat Nov 5 12:12:36 EST 2005 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://www.clkroot.net/security/nb_root.asc --nextPart5418983.vW4Y3AATdm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDcIP4z38ton5LGeIRAmpcAKCCS26KPGmPxRKrLJuknpxRPYdCgACgl6ou FESQGSg6PrWMmXbp2F1+i8w= =bcZs -----END PGP SIGNATURE----- --nextPart5418983.vW4Y3AATdm--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511080554.48373.nb_root>