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 this doesn't touch any working code, because the CE port is
currently broken anyway. Further, the changes compile, but since there
are various other bits and pieces still missing, it is impossible to
test it yet.

So perhaps it is better to use thread_nt.h now on WinCE?

Mark?

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 working on CE
these days...

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.

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.

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 fails, so
intermediate calls don't clobber that value.

The introduction of "int e" is redundant now, right?

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 formats it, so I 
chose 'unsigned' as one that IMHO most likely matches it. That is also 
the reason for the two different error messages, otherwise I don't 
think it makes a big difference.

> 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 formats it, so I 
> chose 'unsigned' as one that IMHO most likely matches it. 

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?

> That is also 
> the reason for the two different error messages, otherwise I don't 
> think it makes a big difference.

Introducing an unnecessary variable should be avoided; this is just
cruft that accumulates. Please remove both variables.

> 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 
GetLastError(). It probably won't change errno, since it is just 
implemented as a call to the win32 API GetCurrentThreadId(). Still, 
when I have a function that fails and provides additional info through 
errno or GetLastError(), I personally prefer to save that value ASAP 
instead of relying on the fact that some call in between doesn't touch 
it.

I don't really care too much about this piece of code, since it's just 
debug output, but in other cases (like #4906) making such distinction 
is crucial. Since people might read and copy the code, I prefer to 
give them a good example. If you feel differently, just drop me a note 
and I'll change it.

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 explain what the variables are good for, and
committed the patch as r68542, r68543.