support for posix semaphores.

[ 960406 ] unblock signals in threads

although the changes do not correspond exactly to any patch attached to
that report.

Non-main threads no longer have all signals masked.

A different interface to readline is used.

The handling of signals inside calls to PyOS_Readline is now rather
different.

These changes are all a bit scary!  Review and cross-platform testing
much appreciated.

is too expensive on FreeBSD's KSE threading infrastructure and
even test_threadedimport fails on default setting.

Python/thread_pthread.h.

Cygwin's pthread_sigmask() implementation appears to be buggy. This
patch works around this problem by using sigprocmask() instead.

This patch is implemented in a general way so it could be used by other
platforms too. If this approach is deemed too risky, then I can work up
a patch that just hacks Python/thread_pthread.h for Cygwin.

Note that I tested this patch against 2.3c1 under Red Hat Linux 8.0 too.

[snip]
And finally, I need someone to regenerate pyconfig.h.in and configure
with the same versions of the autotools that are normally used by
Python.

Neal kindly regenerated pyconfig.h.in and configure for me.

This closes SF patch #504215.

on a function pointer formal argument called "destructor", which is typedeffed
as a different function pointer type in object.h.

This changes Pythread_start_thread() to return the thread ID, or -1
for an error.  (It's technically an incompatible API change, but I
doubt anyone calls it.)

Check for pthread_sigmask before using it. Fixes remaining problem in #470781.

   This patch updates Python/thread_pthread.h to mask all
   signals for any thread created. This will keep all
   signals masked for any thread that isn't the initial
   thread. For Solaris and Linux, the two platforms I was
   able to test it on, it solves bug #465673 (pthreads
   need signal protection) and probably will solve bug
   #219772 (Interactive InterPreter+ Thread -> core dump
   at exit).

   I'd be great if this could get some testing on other
   platforms, especially HP-UX pre 11.00 and post 11.00,
   as I had to make some guesses for the DCE thread case.
   AIX is also a concern as I saw some mention of using
   sigthreadmask() as a pthread_sigmask() equivalent, but
   this patch doesn't use sigthreadmask(). I don't have
   access to AIX.

by bbrox@bbrox.org / lionel.ulmer@free.fr.

This adds a configure check and if all goes well turns on the
PTHREAD_SCOPE_SYSTEM thread attribute for new threads.

This should remove the need to add tiny sleeps at the start of threads
to allow other threads to be scheduled.

not enough for Python. Increased the stacksize to a (somewhat arbitrary)
64KB.

This should match the situation in the 1.6b1 tree.

- Fix bug in thread_pthread.h::PyThread_get_thread_ident() where
  sizeof(pthread) < sizeof(long).
- Add 'configure' for:
	- SIZEOF_PTHREAD is pthread_t can be included via <pthread.h>
	- setting Monterey system name
	- appropriate CC,LINKCC,LDSHARED,OPT, and CCSHARED for Monterey
- Add section in README for Monterey build

declarations yet, those come later.

The common technique for printing out a pointer has been to cast to a long
and use the "%lx" printf modifier. This is incorrect on Win64 where casting
to a long truncates the pointer. The "%p" formatter should be used instead.

The problem as stated by Tim:
> Unfortunately, the C committee refused to define what %p conversion "looks
> like" -- they explicitly allowed it to be implementation-defined. Older
> versions of Microsoft C even stuck a colon in the middle of the address (in
> the days of segment+offset addressing)!

The result is that the hex value of a pointer will maybe/maybe not have a 0x
prepended to it.


Notes on the patch:

There are two main classes of changes:
- in the various repr() functions that print out pointers
- debugging printf's in the various thread_*.h files (these are why the
patch is large)


Closes SourceForge patch #100505.

"""
Spec says that on success pthread_create returns 0. It does not say
that an error code will be < 0. Linux glibc2 pthread_create() returns
ENOMEM (12) when one exceed process limits. (It looks like it should
return EAGAIN, but that's another story.)

For reference, see:
http://www.opengroup.org/onlinepubs/7908799/xsh/pthread_create.html
"""

[I have a feeling that similar bugs were fixed before; perhaps someone
could check that all error checks no check for != 0?]

names in the source code (they already had those for the linker,
through some smart macros; but the source still had the old, un-Py names).

Also (non-BSDI specific):

- Change the CHECK_STATUS() macro so it tests for nonzero error codes
instead of negative error codes only (this was needed for BSDI, but
appears to be correct according to the PTHREADS spec).

- use memset() to zero out the allocated lock structure.  Again, this
was needed for BSDI, but can't hurt elsewhere either.

(which is not a POSIX threads call!).  Reported and confirmed by Brad
Howes.

Reported by Jonathan Giddy.

According to Vladimir Marangozov, this is necessary for AIX, where
high optimization levels inline this function and then get it wrong :-(