From owner-svn-src-head@FreeBSD.ORG Sat Mar 21 22:38:07 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B4D31065674 for ; Sat, 21 Mar 2009 22:38:07 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from mail-out1.fuse.net (mail-out1.fuse.net [216.68.8.175]) by mx1.freebsd.org (Postfix) with ESMTP id B34BF8FC17 for ; Sat, 21 Mar 2009 22:38:06 +0000 (UTC) (envelope-from cokane@FreeBSD.org) X-CNFS-Analysis: v=1.0 c=1 a=r_5zXaxxhK4A:10 a=SrmVwFdnOH0A:10 a=mDV3o1hIAAAA:8 a=iXrWV3IHTMQtWm9SJiAA:9 a=X-D4vy8NFgGkqlJuF_YA:7 a=wFsLiGvrkMBix0cfZpiivGM1HdMA:4 a=LY0hPdMaydYA:10 a=6CIx0o2FfOGwQPuIGgIA:9 a=_6ckyramvSZzqsk_hj1p5-sESLUA:4 a=rPt6xJ-oxjAA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: gwout1 smtp.mail=cokane@FreeBSD.org; spf=softfail Received-SPF: softfail (gwout1: transitional domain FreeBSD.org does not designate 74.215.227.9 as permitted sender) Received: from [74.215.227.9] ([74.215.227.9:50463] helo=discordia) by gwout1 (envelope-from ) (ecelerity 2.2.2.37 r(28805/28810M)) with ESMTP id F6/21-27669-D4C65C94; Sat, 21 Mar 2009 18:38:05 -0400 Received: by discordia (Postfix, from userid 103) id 1F24435A7F1; Sat, 21 Mar 2009 18:38:05 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id 0DE1035A7E0; Sat, 21 Mar 2009 18:37:58 -0400 (EDT) From: Coleman Kane To: Bruce Simpson In-Reply-To: <49C4EEB2.4080507@incunabulum.net> 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> <49C4EEB2.4080507@incunabulum.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-m9HS7Bx7IKXHzeTQgbB6" Organization: FreeBSD Project Date: Sat, 21 Mar 2009 18:36:32 -0400 Message-Id: <1237674992.1690.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, Vasil Dimov , Sam Leffler , Robert Watson , svn-src-head@freebsd.org Subject: Re: svn commit: r189828 - in head: include sys/sys X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 22:38:07 -0000 --=-m9HS7Bx7IKXHzeTQgbB6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-03-21 at 13:42 +0000, Bruce Simpson wrote: > Robert Watson wrote: > > On Fri, 20 Mar 2009, Coleman Kane wrote: > > > >> I've found that many of the GNU apps are notorious for this. I really=20 > >> can't say that I know why libassuan or gnupg explicitly require GNU=20 > >> pth, rather than first attempting to use POSIX pthread API. Their=20 > >> configure scripts both want to search for and run pth-config, and=20 > >> fail to enable some sort of threaded features if it doesn't exist. I=20 > >> already tried removing pth stuff from both port Makefiles to see what=20 > >> would happen. I didn't spend much time on it after I figured out that=20 > >> devel/pth would just work if I removed the signal.h include. > >> > >> I am guessing that some non-standard extensions which GNU pth=20 > >> provides are not provided by the normal POSIX spec. > >> > >> In fact, libassuan just goes ahead and uses a bunch of pth_*=20 > >> overrides for dealing with them in a thread-safe manner (waitpid,=20 > >> read, write, select, usleep). > > > > Historically, pthreads implementations were highly variable in=20 > > quality, completeness, etc. It wouldn't surprise me if the=20 > > persistence of applications linking against pth isn't, in part, a=20 > > response to that (now-historic) situation. >=20 > No, this isn't the only reason. There are a few issues with threading=20 > and fork() -- other implementations support forking and rethreading=20 > processes, something which bends the POSIX rules (it is not expressly=20 > forbidden by them), but ours hasn't. This was causing some of the Python=20 > regression tests to fail for 'multiprocessing' and 'threading'. >=20 > Since POSIX semaphores appear to be fixed, however, we should be able to=20 > get away with building Python on FreeBSD with them natively. kib@ has=20 > committed the rtld fix which makes this possible in 8-CURRENT. For now,=20 > ie until such fixes can be MFCed, I've committed support to the=20 > lang/python26 port to enable it to be built against GNU Pth. >=20 > cheers > BMS =46rom what I can tell, pth provides a superset of the POSIX thread API. GnuPG and libassuan use some of the higher-level APIs provided by pth (such as pth's implementation of stdio functions). Namely, the functions described here: * http://www.gnu.org/software/pth/pth-manual.html#generalized_posix_r= eplacement_api * http://www.gnu.org/software/pth/pth-manual.html#standard_posix_repl= acement_api These appear to provide thread-blocking versions of the standard-C I/O calls, rather than the process-blocking variants that are common. Basically, it comes with pre-written recipes for common multi-threaded I/O problems. GnuPG and libassuan use this part of Pth's API, rather than rolling their own I/O routines based upon POSIX or SUS standards. --=20 Coleman Kane --=-m9HS7Bx7IKXHzeTQgbB6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAknFa+sACgkQcMSxQcXat5eiYgCghLwt5t88/y0uv3gxGH4HbRmU KcEAn1yjHhszdCH3oqP1k6zWFiMsFG2f =oR3u -----END PGP SIGNATURE----- --=-m9HS7Bx7IKXHzeTQgbB6--