This is the mail archive of the
mailing list for the pthreas-win32 project.
Re: Pthreads-w32 project still alive?
- From: Ross Johnson <rpj at callisto dot canberra dot edu dot au>
- To: "Gianlucaspm at hotmail dot com" <gianlucaspm at hotmail dot com>
- Cc: pthreads-win32 at sources dot redhat dot com
- Date: Thu, 02 Nov 2006 14:13:57 +1100
- Subject: Re: Pthreads-w32 project still alive?
- References: <BAY102-DAV94B80F3D363C32BB231F8BBF80@phx.gbl>
- Reply-to: Ross dot Johnson at homemail dot com dot au
Is the project still alive?
If so, is there any planning for the pthreads implementation of process
The project is not dead, but dormant, in that it is in a working stable
state. There have been no critical bugs reported since 2.7.0 and the
project has almost fulfilled it's original intended scope (as much as is
practical at least) of implementing the Threads section of the POSIX API.
Process Shared primitives have been sitting in the "hard" basket since
the start of the project. At first glance it looks as if all we need to
do is call the appropriate Win32 "named" sync routines, but I believe
this is not the way to go for the following reasons. First, we would
need to manage the internal lists of [random] names and guarantee that
they won't ever conflict with names in an application, and there are
other issues with Win32 named objects (security etc). Second, real
pthreads implementations use shared memory in combination with process
shared sync primitives, and that means, for source level portability, we
would need to implement enough of the POSIX shared memory API anyway
even if we did use these named objects. I have a feeling there would be
other undesirable side effects if pthreads-win32 doesn't use a similar
So my preference if implemented in pthreads-win32 is for fully
shared-memory sync primitives and, with that in mind, I had been
gradually trying to deal with the third and final issue - to redefine
pthreads-win32 sync primitives (at least those that should be process
shared) as a prerequisite to be properly memory sharable. Various code
rewrites and ideas from several contributors over time to improve speed,
reliability and behaviour etc. has gotten us much closer to that
situation, with more use of Interlocked instructions replacing Win32
kernel calls. That is where we are in 2.7.0, which is working well if
the absence of bug reports is any indication.
POSIX threads primitives that are candidates for process sharing are:
IIRC, the semaphore implementation is totally Interlocked based now.
Mutexes are based on Interlocked instructions and pthreads semaphores,
so they too are potentially sharable. Condition Variables are based on
pthreads semaphores and pthreads mutexes, and finally, Read/Write Locks
are based on pthreads semaphores, mutexes, and condition variables.
Success here would also mean that message queues could be implemented to
work between processes. There is contributed code (in the contrib area I
think) that fully implements shared MQs but in pthreads-win32 they work
only within the same process. This code has never been merged into the
library because of this - because I didn't want to have to deal with
reports about MQs not working etc.
Having said that, I haven't had the time, resources or commitment lately
to initiate new work on the project, and there have been very few, if
any, requests for this feature in particular to motivate progress.
Ideas, suggestions and contributions are welcome though.
Thanks a lot for your past (and I hope future) work,
( 0 0 )
( =:.:= )
( ( ) )
( ( ) )
o ( ( ) )