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"

Reply via email to