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 > >> 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. > > No, this isn't the only reason. There are a few issues with threading > and fork() -- other implementations support forking and rethreading > processes, something which bends the POSIX rules (it is not expressly > forbidden by them), but ours hasn't. This was causing some of the Python > regression tests to fail for 'multiprocessing' and 'threading'. > > Since POSIX semaphores appear to be fixed, however, we should be able to > get away with building Python on FreeBSD with them natively. kib@ has > committed the rtld fix which makes this possible in 8-CURRENT. For now, > ie until such fixes can be MFCed, I've committed support to the > lang/python26 port to enable it to be built against GNU Pth. > > cheers > BMS
From 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_replacement_api
*
http://www.gnu.org/software/pth/pth-manual.html#standard_posix_replacement_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.
--
Coleman Kane
signature.asc
Description: This is a digitally signed message part
