Here is a suggested update to thread_nt.c.  It has two significant 
changes:
1) it uses the new and safer _beginthreadex API to start a thread
2) it implements native TLS functions on NT, which are certain to be as 
fast as possible.

- Isn't CreateThread even better?

- Using TLS functions is a good idea, beware though that the number of
TLS slots cannot exceed 1088 on Windows. This should at least be documented.
OTOH since there is only one call to PyThread_create_key in the codebase
(for the GIL), and I found only one more through the Google Code Search,
it's probably not worth the trouble.

No, CreateThread() is not a suitable replacement, because it lacks 
some initialisations of the C library, as explained in the MSDN: 
http://msdn.microsoft.com/en-us/library/ms682453(VS.85).aspx

You are right. 
(My dream is someday to completely get rid of this msvcrt stuff. Only
pure Win32 API)

I do have an issue with the patch's startup code. The prototype for 
the thread entry should be "DWORD WINAPI function(PVOID);". The 
important distinction is the WINAPI part, which resolves to __stdcall 
but doesn't have to. I know that some CE targets actually #define 
__cdecl __stdcall or vice versa, but using WINAPI always works. I'd 
then also change the comment to "...to adapt between our function 
signature and the one used by _createthreadex", as the internally used 
one doesn't mention __cdecl.

No, the startup function for beginthreadex() must be __stdcall.  From 
the docs:

start_address
Start address of a routine that begins execution of a new thread. For 
_beginthread, the calling convention is either __cdecl or __clrcall; 
for _beginthreadex, it is either __stdcall or __clrcall.

(__clrcall is for managed code which doesn't apply).

Do not confuse beginthreadex() with CreateThread even though they have 
similar arguments.  The former is for use with programs using the crt.

See http://msdn.microsoft.com/en-us/library/kdzttdcb.aspx for details.

Amaury, Where did you find the value 1088 for maximum TLS slots?  The 
documentation mentions the error condidion TLS_OUT_OF_INDEXES (which I 
should check for, I suppose), but nothing else.

You're right, Kristján, sorry for the noise. Shouldn't make claims 
before being fully awake....

Committed this as revision: 68455

Windows NT (3.1, and a number of later versions) only support 64 TLS
keys. Starting with Windows 2000, they added another page per thread for
TLS, giving an addition 1024 TLS slots, for a total of 1088 TLS slots.
FWIW, Win 9.x supported 80 TLS slots. See

http://www.nynaeve.net/?p=181
http://msdn.microsoft.com/en-us/library/ms686749.aspx
http://bugs.python.org/file11141/thread_nt.patch

TLS slots are typically considered a scarce resource, so that
programming language implementations typically don't allow applications
direct allocation of TLS slots. Instead, most runtimes I know of will
allocate a single TLS slot for themselves, which then is filled with an
array or a dictionary.

Please add a Misc/NEWS entry for this change.

Note, see defect 4906 for fallout caused by this checkin.

Misc/NEWS updated in revision: 68544

Note, this has been ported to py3k in http://svn.python.org/view?
view=rev&rev=68543