Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
> Le mercredi 27 janvier 2010 à 10:37 +0000, Marc-Andre Lemburg a écrit :
>>
>> I find it rather strange that Python 3.x now only supports
>> NT and POSIX threads in ceval while it still supports the
>> whole set of other thread implementations for the _thread
>> module.
>>
>> Has this been discussed on python-dev ?
> 
> Yes, it was. See
> http://mail.python.org/pipermail/python-dev/2009-October/093276.html
> All these thread_*.h files are still there, but most of them are
> deprecated (see the #error's in thread.c). It's the consensus that came
> out on the mailing-list.
> 
> The one exception is OS/2, which is "supported" as long as Andrew
> McIntyre (or someone else, of course) takes care about it. It was
> decided that OS/2 compatibility wasn't important enough to bar adding
> new features or making improvements.

The arguments given in that thread sound a bit strange to me:
just because there were no changes to a few files, doesn't really
say anything about whether they contain working code or not.

In any case, the new GIL implementation as it stands makes
supporting any of those additional threading implementations
a moot case.

You could just as well remove them right now: if the GIL doesn't
work on OS/2, then having support for it in the _thread module
isn't really worth much, is it ?

Regardless, instead of now having two places where threading is
implemented, we should just have one: the portable thread library and
extend this as necessary.

>> Why can't the code necessary to get the new GIL working be
>> added to Sjoerd's portable thread library ?
> 
> The condition variable "emulation" used by the new GIL under Windows is
> not valid as a general condition variable mechanism; this is mentioned
> in ceval_gil.h, and a link is given to a much more complicated (but
> valid) condition variable emulation. Therefore, I think it could be
> detrimental to expose it publicly.

By moving all the thread support code to the thread library,
you don't really expose anything (the lib is only used internally
by Python), you just reorganize the code in a more natural and
easier to maintain way.

If you think that the win32 emulation shouldn't be
used for non-GIL purposes, then just add a comment to
those APIs.

With just NT and POSIX thread support, I think backporting the
new GIL implementation to 2.7 is not possible - we'd have to go
through a standard PEP 11 deprecation process and there are not
enough 2.x releases left for that. It could only be backported
as optional feature, to be enabled by a configure option.