From aaa4964a2277a1e265da4e7b91d5b1e3c3faa84e Mon Sep 17 00:00:00 2001 From: marha Date: Mon, 17 Jan 2011 18:27:35 +0000 Subject: cvs update pthreads --- pthreads/WinCE-PORT | 439 ++++++++++++++++++++++++++-------------------------- 1 file changed, 222 insertions(+), 217 deletions(-) (limited to 'pthreads/WinCE-PORT') diff --git a/pthreads/WinCE-PORT b/pthreads/WinCE-PORT index f5981a9db..16daa8d34 100644 --- a/pthreads/WinCE-PORT +++ b/pthreads/WinCE-PORT @@ -1,217 +1,222 @@ -NOTE: The comments in this file relate to the original WinCE port -done by Tristan Savatier. The semaphore routines have been -completely rewritten since (2005-04-25), having been progressively -broken more and more by changes to the library. All of the semaphore -routines implemented for W9x/WNT/2000 and up should now also work for -WinCE. Also, pthread_mutex_timedlock should now work. [RPJ] - ----- - -Some interesting news: - -I have been able to port pthread-win32 to Windows-CE, -which uses a subset of the WIN32 API. - -Since we intend to keep using pthread-win32 for our -Commercial WinCE developments, I would be very interested -if WinCE support could be added to the main source tree -of pthread-win32. Also, I would like to be credited -for this port :-) - -Now, here is the story... - -The port was performed and tested on a Casio "Cassiopeia" -PalmSize PC, which runs a MIP processor. The OS in the -Casio is WinCE version 2.11, but I used VC++ 6.0 with -the WinCE SDK for version 2.01. - -I used pthread-win32 to port a heavily multithreaded -commercial application (real-time MPEG video player) -from Linux to WinCE. I consider the changes that -I have done to be quite well tested. - -Overall the modifications that we had to do are minor. - -The WinCE port were based on pthread-win32-snap-1999-05-30, -but I am certain that they can be integrated very easiely -to more recent versions of the source. - -I have attached the modified source code: -pthread-win32-snap-1999-05-30-WinCE. - -All the changes do not affect the code compiled on non-WinCE -environment, provided that the macros used for WinCE compilation -are not used, of course! - -Overall description of the WinCE port: -------------------------------------- - -Most of the changes had to be made in areas where -pthread-win32 was relying on some standard-C librairies -(e.g. _ftime, calloc, errno), which are not available -on WinCE. We have changed the code to use native Win32 -API instead (or in some cases we made wrappers). - -The Win32 Semaphores are not available, -so we had to re-implement Semaphores using mutexes -and events. - -Limitations / known problems of the WinCE port: ----------------------------------------------- - -Not all the semaphore routines have been ported -(semaphores are defined by Posix but are not part -pf pthread). I have just done enough to make -pthread routines (that rely internally on semaphores) -work, like signal conditions. - -I noticed that the Win32 threads work slightly -differently on WinCE. This may have some impact -on some tricky parts of pthread-win32, but I have -not really investigated. For example, on WinCE, -the process is killed if the main thread falls off -the bottom (or calls pthread_exit), regardless -of the existence of any other detached thread. -Microsoft manual indicates that this behavior is -deffirent from that of Windows Threads for other -Win32 platforms. - - -Detailed descriptions of the changes and rationals: - ------------------------------------- -- use a new macro NEED_ERRNO. - -If defined, the code in errno.c that defines a reentrant errno -is compiled, regardless of _MT and _REENTRANT. - -Rational: On WinCE, there is no support for , or -any other standard C library, i.e. even if _MT or _REENTRANT -is defined, errno is not provided by any library. NEED_ERRNO -must be set to compile for WinCE. - ------------------------------------- -- In implement.h, change #include to #include "semaphore.h". - -Rational: semaphore.h is provided in pthread-win32 and should not -be searched in the systems standard include. would not compile. -This change does not seem to create problems on "classic" win32 -(e.g. win95). - ------------------------------------- -- use a new macro NEED_CALLOC. - -If defined, some code in misc.c will provide a replacement -for calloc, which is not available on Win32. - - ------------------------------------- -- use a new macro NEED_CREATETHREAD. - -If defined, implement.h defines the macro _beginthreadex -and _endthreadex. - -Rational: On WinCE, the wrappers _beginthreadex and _endthreadex -do not exist. The native Win32 routines must be used. - ------------------------------------- -- in misc.c: - -#ifdef NEED_DUPLICATEHANDLE - /* DuplicateHandle does not exist on WinCE */ - self->threadH = GetCurrentThread(); -#else - if( !DuplicateHandle( - GetCurrentProcess(), - GetCurrentThread(), - GetCurrentProcess(), - &self->threadH, - 0, - FALSE, - DUPLICATE_SAME_ACCESS ) ) - { - free( self ); - return (NULL); - } -#endif - -Rational: On WinCE, DuplicateHandle does not exist. I could not understand -why DuplicateHandle must be used. It seems to me that getting the current -thread handle with GetCurrentThread() is sufficient, and it seems to work -perfectly fine, so maybe DuplicateHandle was just plain useless to begin with ? - ------------------------------------- -- In private.c, added some code at the beginning of ptw32_processInitialize -to detect the case of multiple calls to ptw32_processInitialize. - -Rational: In order to debug pthread-win32, it is easier to compile -it as a regular library (it is not possible to debug DLL's on winCE). -In that case, the application must call ptw32_rocessInitialize() -explicitely, to initialize pthread-win32. It is safer in this circumstance -to handle the case where ptw32_processInitialize() is called on -an already initialized library: - -int -ptw32_processInitialize (void) -{ - if (ptw32_processInitialized) { - /* - * ignore if already initialized. this is useful for - * programs that uses a non-dll pthread - * library. such programs must call ptw32_processInitialize() explicitely, - * since this initialization routine is automatically called only when - * the dll is loaded. - */ - return TRUE; - } - ptw32_processInitialized = TRUE; - [...] -} - ------------------------------------- -- in private.c, if macro NEED_FTIME is defined, add routines to -convert timespec_to_filetime and filetime_to_timespec, and modified -code that was using _ftime() to use Win32 API instead. - -Rational: _ftime is not available on WinCE. It is necessary to use -the native Win32 time API instead. - -Note: the routine timespec_to_filetime is provided as a convenience and a mean -to test that filetime_to_timespec works, but it is not used by the library. - ------------------------------------- -- in semaphore.c, if macro NEED_SEM is defined, add code for the routines -_increase_semaphore and _decrease_semaphore, and modify significantly -the implementation of the semaphores so that it does not use CreateSemaphore. - -Rational: CreateSemaphore is not available on WinCE. I had to re-implement -semaphores using mutexes and Events. - -Note: Only the semaphore routines that are used by pthread are implemented -(i.e. signal conditions rely on a subset of the semaphores routines, and -this subset works). Some other semaphore routines (e.g. sem_trywait) are -not yet supported on my WinCE port (and since I don't need them, I am not -planning to do anything about them). - ------------------------------------- -- in tsd.c, changed the code that defines TLS_OUT_OF_INDEXES - -/* TLS_OUT_OF_INDEXES not defined on WinCE */ -#ifndef TLS_OUT_OF_INDEXES -#define TLS_OUT_OF_INDEXES 0xffffffff -#endif - -Rational: TLS_OUT_OF_INDEXES is not defined in any standard include file -on WinCE. - ------------------------------------- -- added file need_errno.h - -Rational: On WinCE, there is no errno.h file. need_errno.h is just a -copy of windows version of errno.h, with minor modifications due to the fact -that some of the error codes are defined by the WinCE socket library. -In pthread.h, if NEED_ERRNO is defined, the file need_errno.h is -included (instead of ). - - --- eof +NOTE: The comments in this file relate to the original WinCE port +done by Tristan Savatier. The semaphore routines have been +completely rewritten since (2005-04-25), having been progressively +broken more and more by changes to the library. All of the semaphore +routines implemented for W9x/WNT/2000 and up should now also work for +WinCE. Also, pthread_mutex_timedlock should now work. + +Additional WinCE updates have been applied since this as well. Check the +ChangeLog file and search for WINCE for example. (2007-01-07) + +[RPJ] + +---- + +Some interesting news: + +I have been able to port pthread-win32 to Windows-CE, +which uses a subset of the WIN32 API. + +Since we intend to keep using pthread-win32 for our +Commercial WinCE developments, I would be very interested +if WinCE support could be added to the main source tree +of pthread-win32. Also, I would like to be credited +for this port :-) + +Now, here is the story... + +The port was performed and tested on a Casio "Cassiopeia" +PalmSize PC, which runs a MIP processor. The OS in the +Casio is WinCE version 2.11, but I used VC++ 6.0 with +the WinCE SDK for version 2.01. + +I used pthread-win32 to port a heavily multithreaded +commercial application (real-time MPEG video player) +from Linux to WinCE. I consider the changes that +I have done to be quite well tested. + +Overall the modifications that we had to do are minor. + +The WinCE port were based on pthread-win32-snap-1999-05-30, +but I am certain that they can be integrated very easiely +to more recent versions of the source. + +I have attached the modified source code: +pthread-win32-snap-1999-05-30-WinCE. + +All the changes do not affect the code compiled on non-WinCE +environment, provided that the macros used for WinCE compilation +are not used, of course! + +Overall description of the WinCE port: +------------------------------------- + +Most of the changes had to be made in areas where +pthread-win32 was relying on some standard-C librairies +(e.g. _ftime, calloc, errno), which are not available +on WinCE. We have changed the code to use native Win32 +API instead (or in some cases we made wrappers). + +The Win32 Semaphores are not available, +so we had to re-implement Semaphores using mutexes +and events. + +Limitations / known problems of the WinCE port: +---------------------------------------------- + +Not all the semaphore routines have been ported +(semaphores are defined by Posix but are not part +pf pthread). I have just done enough to make +pthread routines (that rely internally on semaphores) +work, like signal conditions. + +I noticed that the Win32 threads work slightly +differently on WinCE. This may have some impact +on some tricky parts of pthread-win32, but I have +not really investigated. For example, on WinCE, +the process is killed if the main thread falls off +the bottom (or calls pthread_exit), regardless +of the existence of any other detached thread. +Microsoft manual indicates that this behavior is +deffirent from that of Windows Threads for other +Win32 platforms. + + +Detailed descriptions of the changes and rationals: + +------------------------------------ +- use a new macro NEED_ERRNO. + +If defined, the code in errno.c that defines a reentrant errno +is compiled, regardless of _MT and _REENTRANT. + +Rational: On WinCE, there is no support for , or +any other standard C library, i.e. even if _MT or _REENTRANT +is defined, errno is not provided by any library. NEED_ERRNO +must be set to compile for WinCE. + +------------------------------------ +- In implement.h, change #include to #include "semaphore.h". + +Rational: semaphore.h is provided in pthread-win32 and should not +be searched in the systems standard include. would not compile. +This change does not seem to create problems on "classic" win32 +(e.g. win95). + +------------------------------------ +- use a new macro NEED_CALLOC. + +If defined, some code in misc.c will provide a replacement +for calloc, which is not available on Win32. + + +------------------------------------ +- use a new macro NEED_CREATETHREAD. + +If defined, implement.h defines the macro _beginthreadex +and _endthreadex. + +Rational: On WinCE, the wrappers _beginthreadex and _endthreadex +do not exist. The native Win32 routines must be used. + +------------------------------------ +- in misc.c: + +#ifdef NEED_DUPLICATEHANDLE + /* DuplicateHandle does not exist on WinCE */ + self->threadH = GetCurrentThread(); +#else + if( !DuplicateHandle( + GetCurrentProcess(), + GetCurrentThread(), + GetCurrentProcess(), + &self->threadH, + 0, + FALSE, + DUPLICATE_SAME_ACCESS ) ) + { + free( self ); + return (NULL); + } +#endif + +Rational: On WinCE, DuplicateHandle does not exist. I could not understand +why DuplicateHandle must be used. It seems to me that getting the current +thread handle with GetCurrentThread() is sufficient, and it seems to work +perfectly fine, so maybe DuplicateHandle was just plain useless to begin with ? + +------------------------------------ +- In private.c, added some code at the beginning of ptw32_processInitialize +to detect the case of multiple calls to ptw32_processInitialize. + +Rational: In order to debug pthread-win32, it is easier to compile +it as a regular library (it is not possible to debug DLL's on winCE). +In that case, the application must call ptw32_rocessInitialize() +explicitely, to initialize pthread-win32. It is safer in this circumstance +to handle the case where ptw32_processInitialize() is called on +an already initialized library: + +int +ptw32_processInitialize (void) +{ + if (ptw32_processInitialized) { + /* + * ignore if already initialized. this is useful for + * programs that uses a non-dll pthread + * library. such programs must call ptw32_processInitialize() explicitely, + * since this initialization routine is automatically called only when + * the dll is loaded. + */ + return TRUE; + } + ptw32_processInitialized = TRUE; + [...] +} + +------------------------------------ +- in private.c, if macro NEED_FTIME is defined, add routines to +convert timespec_to_filetime and filetime_to_timespec, and modified +code that was using _ftime() to use Win32 API instead. + +Rational: _ftime is not available on WinCE. It is necessary to use +the native Win32 time API instead. + +Note: the routine timespec_to_filetime is provided as a convenience and a mean +to test that filetime_to_timespec works, but it is not used by the library. + +------------------------------------ +- in semaphore.c, if macro NEED_SEM is defined, add code for the routines +_increase_semaphore and _decrease_semaphore, and modify significantly +the implementation of the semaphores so that it does not use CreateSemaphore. + +Rational: CreateSemaphore is not available on WinCE. I had to re-implement +semaphores using mutexes and Events. + +Note: Only the semaphore routines that are used by pthread are implemented +(i.e. signal conditions rely on a subset of the semaphores routines, and +this subset works). Some other semaphore routines (e.g. sem_trywait) are +not yet supported on my WinCE port (and since I don't need them, I am not +planning to do anything about them). + +------------------------------------ +- in tsd.c, changed the code that defines TLS_OUT_OF_INDEXES + +/* TLS_OUT_OF_INDEXES not defined on WinCE */ +#ifndef TLS_OUT_OF_INDEXES +#define TLS_OUT_OF_INDEXES 0xffffffff +#endif + +Rational: TLS_OUT_OF_INDEXES is not defined in any standard include file +on WinCE. + +------------------------------------ +- added file need_errno.h + +Rational: On WinCE, there is no errno.h file. need_errno.h is just a +copy of windows version of errno.h, with minor modifications due to the fact +that some of the error codes are defined by the WinCE socket library. +In pthread.h, if NEED_ERRNO is defined, the file need_errno.h is +included (instead of ). + + +-- eof -- cgit v1.2.3