From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Bossom, John" To: 'Tristan Savatier' , pthreads-win32@sourceware.cygnus.com Subject: RE: pthread-win32: WinCE port Date: Wed, 22 Sep 1999 07:52:00 -0000 Message-id: <450FB96A8F51D31186CD00805F95C7DC036CFE@SOTTEXCH62A> X-SW-Source: 1999/msg00095.html Congratulations on your successful port! Here is an exert from a book that describes the PThreads behaviour with regards to exiting the initial thread (a.k.a. main): Multithreaded Programming with PThreads, Bil Lewis, Daniel J. Berg, page 52, "Exiting The Process" "The semantics of exit() are retained in MT programs for POSIX, Win32, and OS/2. When any thread in a process calls exit(), the process exits, returning its memory, system resources, process structure, all LWPs, etc. If main() "falls off the bottom" of the initial thread, the main thread makes an implicit call to exit(), also killing the process. When any other thread falls off the bottom of its initial function, it implicitly calls pthread_exit(), exiting only that one thread. Int the special case in which the main thread calls the thread exit function directly, that thread exits but does not call exit(), and the process continues. This situation is true for POSIX and Win32, but OS/2 requires the main thread to stay alive. Finally, should all user threads exit (the library may create threads for its own use and they will not be counted), the thread library will detect this and call exit() itself. This situation is not typical, however, as you will generally sense when it's time to exit your process, and you should call exit() explicitly." i.e. detached threads do not keep the process alive implicitly. falling off the bottom of the main thread should cause the entire process to terminate. However, you indicate that even if you call pthread_exit in your main thread, the process still dies even though there are active threads... this is where work is required (reference counting/semaphore that keeps track of the # of active threads) -----Original Message----- From: Tristan Savatier [ mailto:tristan@mpegtv.com ] Sent: Tuesday, September 21, 1999 9:47 PM To: pthreads-win32@sourceware.cygnus.com Subject: pthread-win32: WinCE port 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 NO_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. NO_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 NO_CALLOC. If defined, some code in misc.c will provide a replacement for calloc, which is not available on Win32. ------------------------------------ - use a new macro _PTHREAD_CREATETHREAD. If defined, implement.h defined the macro _beginthreadex and _endthreadex, regardless of the value of __CYGWIN32__ and __CYGWIN__. Rational: On WinCE, the wrappers _beginthreadex and _endthreadex do not exist. The native Win32 routines must be used. ------------------------------------ - in misc.c: #ifdef UNDER_CE /* 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 _pthread_processInitialize to detect the case of multiple calls to _pthread_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 _pthread_processInitialize() explicitely, to initialize pthread-win32. It is safer in this circumstance to handle the case where _pthread_processInitialize() is called on an already initialized library: int _pthread_processInitialize (void) { if (_pthread_processInitialized) { /* * ignore if already initialized. this is useful for * programs that uses a non-dll pthread * library. such programs must call _pthread_processInitialize() explicitely, * since this initialization routine is automatically called only when * the dll is loaded. */ return TRUE; } _pthread_processInitialized = TRUE; [...] } ------------------------------------ - in private.c, if macro NO_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 NO_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 pthread_errno.h Rational: On WinCE, there is no errno.h file. pthread_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 NO_ERRNO is defined, the file pthread_errno.h is included (instead of ). -- Regards, -- Tristan Savatier (President, MpegTV LLC) MpegTV: http://www.mpegtv.com - Xaudio: http://www.xaudio.com MPEG.ORG: http://www.mpeg.org - Tel: (415) 864 6466