From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8940 invoked by alias); 2 Nov 2006 14:50:28 -0000 Received: (qmail 8932 invoked by uid 22791); 2 Nov 2006 14:50:27 -0000 X-Spam-Check-By: sourceware.org Received: from mail87.messagelabs.com (HELO mail87.messagelabs.com) (216.82.250.19) by sourceware.org (qpsmtpd/0.31) with SMTP; Thu, 02 Nov 2006 14:50:19 +0000 X-VirusChecked: Checked X-Env-Sender: John.Bossom@Cognos.COM X-Msg-Ref: server-13.tower-87.messagelabs.com!1162479016!30488478!3 X-StarScan-Version: 5.5.10.7; banners=-,-,- Received: (qmail 3692 invoked from network); 2 Nov 2006 14:50:17 -0000 Received: from nomad.cognos.com (HELO nomad.cognos.com) (205.210.232.62) by server-13.tower-87.messagelabs.com with SMTP; 2 Nov 2006 14:50:17 -0000 Received: from sottemail2.ent.ad.cognos.com ([10.67.10.28]) by nomad.cognos.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 09:50:15 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Pthreads-w32 project still alive? Date: Thu, 02 Nov 2006 14:50:00 -0000 Message-ID: <4ABB890A1781774888DB6505E6F0E3B3D0AE7F@sottemail2.ent.ad.cognos.com> In-Reply-To: <45496275.6000605@callisto.canberra.edu.au> From: "Bossom, John" To: , "Gianlucaspm@hotmail.com" Cc: 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/msg00061.txt.bz2 For a portable solution for cross process synchronization you could use a file lock an a well known file. You could use this a sort of a cross process "mutex". FYI... I noticed that the RealTime spec for semaphores support "named" semaphores... If so then you could pass the buck back to the developer to remember the "name" and therefore not require a list... (however, I am unfamiliar with the RealTime library - is it always there?) Cheers John E. Bossom (still lurking deep in the background) =20 -----Original Message----- From: pthreads-win32-owner@sourceware.org [mailto:pthreads-win32-owner@sourceware.org] On Behalf Of Ross Johnson Sent: Wednesday, November 01, 2006 10:14 PM To: Gianlucaspm@hotmail.com Cc: pthreads-win32@sources.redhat.com Subject: Re: Pthreads-w32 project still alive? Gianlucaspm@hotmail.com wrote:=20 > Is the project still alive? > If so, is there any planning for the pthreads implementation of=20 > 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.=20 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 >=20=20 > Thanks a lot for your past (and I hope future) work, Gianluca >=20=20 > () () > ( 0 0 ) > ( =3D:.:=3D ) > ( ) > ( ( ) ) > ( ( ) ) > o ( ( ) ) > (___) (___) =20 This message may contain privileged and/or confidential information. = If you have received this e-mail in error or are not the intended recipient= , you may not use, copy, disseminate or distribute it; do not open any atta= chments, delete it immediately from your system and notify the sender promp= tly by e-mail that you have done so. Thank you.