Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
From: "Robert Collins" <robert DOT collins AT syncretize DOT net>
To: "'Conrad Scott'" <Conrad DOT Scott AT dsl DOT pipex DOT com>
Cc: <cygwin-developers AT cygwin DOT com>
Subject: RE: System-wide mutexes and pthreads
Date: Sat, 15 Jun 2002 21:30:01 +1000
Message-ID: <002101c2145f$fcac3cb0$0200a8c0@lifelesswks>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
In-Reply-To: <087101c21344$59888be0$6132bc3e@BABEL>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000



> -----Original Message-----
> From: cygwin-developers-owner AT cygwin DOT com 
> [mailto:cygwin-developers-owner AT cygwin DOT com] On Behalf Of Conrad Scott
> Sent: Friday, 14 June 2002 11:40 AM

> nb. I'm not sure about what happens if the client forks 
> halfway through the
> attach code being run, since the attach list would be 
> inconsistent, so the
> fork code would need to lock the attach list mutex before it 
> could go ahead.
> There's going to have to be some mutex handling in the fork 
> implementation
> anyhow if any of the dll code uses mutexes. Also note that 
> this will be an
> issue with the current design as well (once it gets mutex'ed that is).

If the client calls fork halfway through, it implies 2 things:
1) The client is using multiple threads.
2) The client is not using atfork() which is the proscribed method for
syncronising multi-threaded programs before forking(). 
So the answer is: tough. It's not our problem.
 
> So: two proposals: the first is to remove the "control" shared memory
> segment and have the clients make requests for all 
> information. The second
> is to strip all the state out of the client-side code, which 
> would make it
> thread-safe too :-)

Cool.
 
> The first seems like a good idea to me, the second is more 
> fuzzy. Has anyone
> any opinions on this? Well, anyone who's read this far anyway :-)

Yes, please go ahead. A patch for 1) will be accepted (presuming the
quality is good :}) immediately. For 2) I'd like to see it once 1) is in
HEAD, and review it then.

Rob