Date: Tue, 05 Apr 2005 21:12:28 +0300 From: Petri Helenius <pete@he.iki.fi> To: Sean Chittenden <sean@gigave.com> Cc: threads@freebsd.org Subject: Re: pthread_acquire() still having issues? Message-ID: <4252D50C.3000007@he.iki.fi> In-Reply-To: <20050405174828.GQ1527@sean.gigave.com> References: <20050405174828.GQ1527@sean.gigave.com>
next in thread | previous in thread | raw e-mail | index | archive | help
That refers to the linuxthreads issue, right? It does not describe the alleged pthread issue to any great detail. Pete Sean Chittenden wrote: >I'd nearly call this Nagios FUD, but since I haven't seen anything >about this I thought I'd as for the record. From the Known Issues >section on: > >http://nagios.sourceforge.net/docs/2_0/whatsnew.html > >"There are a few known issues with the Nagios 2.0 code at the >moment. Hopefully some of these will be fixed before 2.0 is released >as stable... FreeBSD and threads. On FreeBSD there's a native >user-level implementation of threads called 'pthread' and there's also >an optional ports collection 'linuxthreads' that uses kernel >hooks. Some folks from Yahoo! have reported that using the pthread >library causes Nagios to pause under heavy I/O load, causing some >service check results to be lost. Switching to linuxthreads seems to >help this problem, but not fix it. The lock happens in liblthread's >__pthread_acquire() - it can't ever acquire the spinlock. It happens >when the main thread forks to execute an active check. On the second >fork to create the grandchild, the grandchild is created by fork, but >never returns from liblthread's fork wrapper, because it's stuck in >__pthread_acquire(). Maybe some FreeBSD users can help out with this >problem." > >I cruised through the lists and didn't see anything. Has this been >addressed or is this still a current issue that folks are aware of? >-sc > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4252D50C.3000007>