svn commit: r189828 - in head: include sys/sys
bms at incunabulum.net
Sat Mar 21 06:42:14 PDT 2009
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.
More information about the svn-src-all