[issue4893] Use separate thread support code under MS Windows CE

Martin v. Löwis added the comment: I see. Whether the call to PyThread_get_thread_ident comes before the access to errno (in the original version) depends on the compiler, of course. Also, this function should be trusted to not affect the last error, since it can't fail. I've added a comment to

[issue4893] Use separate thread support code under MS Windows CE

Ulrich Eckhardt added the comment: > That's all fine, but why do you need a variable named "e" in > the first place? Can't you leave the code as it was before?" There is an intermediate call to a function that retrieves the thread's ID. That function may or may not change the output of GetLas

[issue4893] Use separate thread support code under MS Windows CE

Martin v. Löwis added the comment: > Actually, I made the distinction between the 'int e' and the 'unsigned > e' consciously. When using 'errno', using an 'int' is correct. When > using GetLastError(), I would have used a win32 DWORD if there was a > format sequence that correctly and portably

[issue4893] Use separate thread support code under MS Windows CE

Ulrich Eckhardt added the comment: Actually, I made the distinction between the 'int e' and the 'unsigned e' consciously. When using 'errno', using an 'int' is correct. When using GetLastError(), I would have used a win32 DWORD if there was a format sequence that correctly and portably format

[issue4893] Use separate thread support code under MS Windows CE

Martin v. Löwis added the comment: The introduction of "int e" is redundant now, right? ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue4893] Use separate thread support code under MS Windows CE

Ulrich Eckhardt added the comment: Okay, hopefully this patch is final. The last one was using 'errno' in debug mode, but under CE using CreateThread() it should use GetLastError(). I also took the liberty of saving that error information for both variants directly after creating the thread fail

[issue4893] Use separate thread support code under MS Windows CE

Ulrich Eckhardt added the comment: Okay, the changes necessary to the NT thread code are rather minimal, see attached patch. The file thread_wince.c could then be removed, too. I also removed a comment which was left over from the version before but doesn't apply any more. Added file: http://b

[issue4893] Use separate thread support code under MS Windows CE

Ulrich Eckhardt added the comment: The thread code is unaffected by the Unicode/ANSI issues, but CE doesn't have _beginthread[ex], which are mandatory for the desktop variants. I have checkin 68455 and I will try to compile the new NT code under CE to estimate how large the changes are.

[issue4893] Use separate thread support code under MS Windows CE

Mark Hammond added the comment: Early windows CE devices were very crippled, and IIRC, only the Unicode version of the API existed, and (also IIRC) this was well before Python had builtin unicode. I agree with Martin; it is probably worth investigating how much effort it is to get thread_nt.h w

[issue4893] Use separate thread support code under MS Windows CE

Martin v. Löwis added the comment: So perhaps it is better to use thread_nt.h now on WinCE? Mark? -- nosy: +loewis, mhammond ___ Python tracker ___ _

[issue4893] Use separate thread support code under MS Windows CE

New submission from Ulrich Eckhardt : There is a separate file thread_wince.h for use with CE, but that is firstly not used due to a missing macro definition and secondly it doesn't compile as it is. The attached patch defines WINCE_THREADS for CE and makes the file at least compile. Note that t