| msg79466 - (view) |
Author: Ulrich Eckhardt (eckhardt) |
Date: 2009-01-09 12:01 |
| 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. |
|
|
| msg79492 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2009-01-09 19:40 |
| So perhaps it is better to use thread_nt.h now on WinCE? Mark? |
|
|
| msg79521 - (view) |
Author: Mark Hammond (mhammond) * |
Date: 2009-01-09 22:36 |
| 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... |
|
|
| msg79533 - (view) |
Author: Ulrich Eckhardt (eckhardt) |
Date: 2009-01-10 09:07 |
| 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. |
|
|
| msg79595 - (view) |
Author: Ulrich Eckhardt (eckhardt) |
Date: 2009-01-11 11:03 |
| 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. |
|
|
| msg79603 - (view) |
Author: Ulrich Eckhardt (eckhardt) |
Date: 2009-01-11 16:36 |
| 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. |
|
|
| msg79607 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-01-11 18:44 |
| The introduction of "int e" is redundant now, right? |
|
|
| msg79620 - (view) |
Author: Ulrich Eckhardt (eckhardt) |
Date: 2009-01-11 19:57 |
| 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. |
|
|
| msg79624 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-01-11 20:22 |
| > 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. |
|
|
| msg79626 - (view) |
Author: Ulrich Eckhardt (eckhardt) |
Date: 2009-01-11 20:43 |
| > 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. |
|
|
| msg79652 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-01-12 08:22 |
| 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. |
|
|