Date: Fri, 20 Mar 2009 22:17:02 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Coleman Kane <cokane@FreeBSD.org> Cc: svn-src-head@freebsd.org, Vasil Dimov <vd@freebsd.org>, svn-src-all@freebsd.org, Sam Leffler <sam@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r189828 - in head: include sys/sys Message-ID: <alpine.BSF.2.00.0903202215270.99520@fledge.watson.org> In-Reply-To: <1237573175.1993.19.camel@localhost> References: <200903142010.n2EKAESF006945@svn.freebsd.org> <20090320140015.GA17645@hub.freebsd.org> <20090320153405.GA62675@zim.MIT.EDU> <49C3BCD4.4030605@freebsd.org> <1237567495.1993.2.camel@localhost> <49C3D518.6070105@freebsd.org> <1237573175.1993.19.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Mar 2009, Coleman Kane wrote: > I've found that many of the GNU apps are notorious for this. I really can't > say that I know why libassuan or gnupg explicitly require GNU pth, rather > than first attempting to use POSIX pthread API. Their configure scripts both > want to search for and run pth-config, and fail to enable some sort of > threaded features if it doesn't exist. I already tried removing pth stuff > from both port Makefiles to see what would happen. I didn't spend much time > on it after I figured out that devel/pth would just work if I removed the > signal.h include. > > I am guessing that some non-standard extensions which GNU pth provides are > not provided by the normal POSIX spec. > > In fact, libassuan just goes ahead and uses a bunch of pth_* overrides for > dealing with them in a thread-safe manner (waitpid, read, write, select, > usleep). Historically, pthreads implementations were highly variable in quality, completeness, etc. It wouldn't surprise me if the persistence of applications linking against pth isn't, in part, a response to that (now-historic) situation. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0903202215270.99520>