I recently came up with a fix for thread support in Python under Cygwin. Jason Tishler and Norman Vine are looking it over, but I'm pretty sure something similar should be used for the Cygwin Python port. This is easily done--simply add a few lines to thread.c and create a new thread_cygwin.h (context diff and new file both provided). But there is a larger issue: The thread interface code in thread_pthread.h uses mutexes and condition variables to emulate semaphores, which are then used to provide Python "lock" and "sema" services. I know this is a common practice since those two thread synchronization primitives are defined in "pthread.h". But it comes with quite a bit of overhead. (And in the case of Cygwin causes race conditions, but that's another matter.) POSIX does define semaphores, though. (In fact, it's in the standard just before Mutexes and Condition Variables.) According to POSIX, they are found in <semaphore.h> and _POSIX_SEMAPHORES should be defined if they work as POSIX expects. If they are available, it seems like providing direct semaphore services would be preferable to emulating them using condition variables and mutexes. thread_posix.h.diff-c is a context diff that can be used to convert thread_pthread.h into a more general POSIX version that will use semaphores if available. thread_cygwin.h would no longer be needed then, since all it does is uses POSIX semaphores directly rather than mutexes/condition vars. Changing the interface to POSIX threads should bring a performance improvement to any POSIX platform that supports semaphores directly. Does this sound like a good idea? Should I create a more thorough set of patch files and submit them? (I haven't been accepted to the python-dev list yet, so please CC me. Thanks.) -Jerry -O Gerald S. Williams, 22Y-103GA : mailto:gsw@agere.com O- -O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661 O- -O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592 O-