svn commit: r189828 - in head: include sys/sys

[Bruce Simpson]

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