I realize it is a leap to transition from a thread (library) agnostic model to one that acknowledges the existance of a thread model, as well as the variations in the threading models.
But I would argue that the POSIX pthread model provides solutions to all of the challenges that you face. I would further argue that in the 8-9 years since POSIX standardized the threading model, many vendors have revised their systems to correctly implement the POSIX model. Arguably, all of the popular and important implementations are there. (See Peter Waltenberg's recent comments in this thread). My suggestion is to implement a (synchronization) solution that strictly adheres to the POSIX-96 or POSIX-2001 standard. You could make it optional (via configure and #ifdefs) for platforms that do not implement mutexes or do not implement them in a sufficiently standard method. These platforms will be no worse off than they are today. Basically, I'm proposing transitioning from a thread library agnostic model to a single threading model -- standard POSIX pthreads. Having a major package like OpenSSL follow the standard will be a huge incentive to users to upgrade to newer releases of the operating systems that support standard (non quirky) POSIX pthreads, and it will be a major incentive to vendors to improve their implementations, if and when necessary. As someone who works for a vendor and lobbies for projects, I can tell you that it is absolutely the case that requirements to run open-source packages such as OpenSSL drive funding of development projects. No doubt porting engineers taking OpenSSL to platforms with non-standard or quirky implementations will submit patches to make OpenSSL work for them, but my strong feeling is that such patches should be carefully weighed before acceptance; the bias should be to adhere to a single pthread model, else we will end up in the soup that you have been understandably avoiding. You could perhaps get started by simply releasing a simple test case that uses and tests the POSIX mutex features you need. We could then build it and see whether we implement the features, and implement them correctly. Take a look sometime at how Samba deals with building on multiple platforms; see http://build.samba.org. Their system makes it easy for a maintainer to get instant feedback on build and test issues across a wide variety of platforms. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Technologies, Maynard, MA USA Voice: +1 978-461-7557; FAX: +1 978-461-3610 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
