Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Mar 2009 18:36:32 -0400
From:      Coleman Kane <cokane@FreeBSD.org>
To:        Bruce Simpson <bms@incunabulum.net>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, Vasil Dimov <vd@freebsd.org>, Sam Leffler <sam@freebsd.org>, Robert Watson <rwatson@FreeBSD.org>, svn-src-head@freebsd.org
Subject:   Re: svn commit: r189828 - in head: include sys/sys
Message-ID:  <1237674992.1690.8.camel@localhost>
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> <alpine.BSF.2.00.0903202215270.99520@fledge.watson.org> <49C4EEB2.4080507@incunabulum.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--=-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--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1237674992.1690.8.camel>