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
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

- Raw text -