Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Subject: Re: fork and mutexs From: Robert Collins To: Jason Tishler Cc: nhv AT cape DOT com, cygwin-developers AT cygwin DOT com, gsmith AT nc DOT rr DOT com In-Reply-To: <20010911123801.B1752@dothill.com> References: <20010911123801 DOT B1752 AT dothill DOT com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1000284268.30377.34.camel@lifelesswks> Mime-Version: 1.0 X-Mailer: Evolution/0.13 (Preview Release) Date: 13 Sep 2001 08:18:08 +1000 X-OriginalArrivalTime: 12 Sep 2001 22:05:12.0458 (UTC) FILETIME=[FEA87EA0:01C13BD6] On Wed, 2001-09-12 at 02:38, Jason Tishler wrote: > Rob, > My strategy is to change Cygwin (at least temporarily) to warn instead > of abort. And, then go to the python-dev list and attempt to fight that > battle. Do you concur? A silent approach is better - otherwise I can just imagine the cygwin list traffic. "Foo works perfectly on Linux, but I get all these warnings here about forking with waiting condition variables. Why is cygwin broken?" If python forks() and immediately exec's then it's not buggy, spec speaking. If python forks() and then does other stuff... well thats not so good... particularly if it used pshared mutex's or cond variables. Although in a certain sense pshared syncronisation is easier, because the new thread can simply be not given ownership of the mutex's and it just has to try and acquire them... BTW: Greg, if you'd like to try that speed comparison between win32pthreads, and cygwin pthreads again, I think you'll like the results... Rob