You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
You are right.
(My dream is someday to completely get rid of this msvcrt stuff. Only
pure Win32 API)
eckhardt commented on Jan 6, 2009
eckhardtmannequin
Mannequin
More actions
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.
kristjanvalur commented on Jan 6, 2009
kristjanvalurmannequin
MannequinAuthor
More actions
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.
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.
eckhardt commented on Jan 6, 2009
eckhardtmannequin
Mannequin
More actions
You're right, Kristján, sorry for the noise. Shouldn't make claims
before being fully awake....
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
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.
Activity
kristjanvalur commentedon Aug 17, 2008
Here is a suggested update to thread_nt.c. It has two significant
changes:
fast as possible.
amauryfa commentedon Jan 5, 2009
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.
eckhardt commentedon Jan 5, 2009
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
amauryfa commentedon Jan 5, 2009
You are right.
(My dream is someday to completely get rid of this msvcrt stuff. Only
pure Win32 API)
eckhardt commentedon Jan 6, 2009
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.
kristjanvalur commentedon Jan 6, 2009
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.
eckhardt commentedon Jan 6, 2009
You're right, Kristján, sorry for the noise. Shouldn't make claims
before being fully awake....
kristjanvalur commentedon Jan 9, 2009
Committed this as revision: 68455
loewis commentedon Jan 9, 2009
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.
loewis commentedon Jan 12, 2009
Please add a Misc/NEWS entry for this change.
kristjanvalur commentedon Jan 12, 2009
Note, see defect 4906 for fallout caused by this checkin.
kristjanvalur commentedon Jan 12, 2009
Misc/NEWS updated in revision: 68544
kristjanvalur commentedon Jan 19, 2009
Note, this has been ported to py3k in http://svn.python.org/view?
view=rev&rev=68543