From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5682 invoked by alias); 2 Nov 2006 03:14:05 -0000 Received: (qmail 5671 invoked by uid 22791); 2 Nov 2006 03:14:03 -0000 X-Spam-Check-By: sourceware.org Received: from mail.canberra.edu.au (HELO mail.canberra.edu.au) (137.92.97.81) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 02 Nov 2006 03:14:01 +0000 Received: from [137.92.9.97] (noopeebs.canberra.edu.au [137.92.9.97]) by mail.canberra.edu.au (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTPA id <0J830090P2BAK7@mail.canberra.edu.au> for pthreads-win32@sources.redhat.com; Thu, 02 Nov 2006 14:13:58 +1100 (EST) Date: Thu, 02 Nov 2006 03:14:00 -0000 From: Ross Johnson Subject: Re: Pthreads-w32 project still alive? In-reply-to: To: "Gianlucaspm@hotmail.com" Cc: pthreads-win32@sources.redhat.com Reply-to: Ross.Johnson@homemail.com.au Message-id: <45496275.6000605@callisto.canberra.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.7 (X11/20060911) References: X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2006/txt/msg00060.txt.bz2 Gianlucaspm@hotmail.com wrote: > Is the project still alive? > If so, is there any planning for the pthreads implementation of process > synchronization primitives? Hi Gianluca, 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 implementation. 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: Semaphores Mutexes Condition Variables Read/Write Locks 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. Regards. Ross > > Thanks a lot for your past (and I hope future) work, > Gianluca > > () () > ( 0 0 ) > ( =:.:= ) > ( ) > ( ( ) ) > ( ( ) ) > o ( ( ) ) > (___) (___)