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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
