Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Subject:	RE: Cygwin Python -- Thread or not to thread...
From:	Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To:	Tim Peters <tim AT zope DOT com>
Cc:	Cygwin <cygwin AT sources DOT redhat DOT com>, Python-List <python-list AT python DOT org>
In-Reply-To:	<BIEJKCLHCIOIHAGOKOLHOEDMCHAA.tim@zope.com>
References:	<BIEJKCLHCIOIHAGOKOLHOEDMCHAA DOT tim AT zope DOT com>
X-Mailer:	Evolution/0.13 (Preview Release)
Date:	26 Sep 2001 08:16:40 +1000
Message-Id:	<1001456201.7752.12.camel@lifelesswks>
Mime-Version:	1.0
X-OriginalArrivalTime:	25 Sep 2001 22:24:18.0881 (UTC) FILETIME=[D1598310:01C14610]

On Wed, 2001-09-26 at 07:17, Tim Peters wrote:
> [Jason Tishler]
> > ...
> > there is one known Cygwin pthreads race condition that can cause a hang,
> > ...
> > test_threadedtempfile hung due to the above mentioned problem.
> > ...
> >     Should I still release my next Cygwin Python distribution with
> >     threading enabled?  Or, should I continue to disabled threading
> >     until the above known Cygwin pthreads issue is resolved?
> 
> Poor end users should never need to deal with thread race bugs, and
> test_threadedtempfile is merely testing the robustness of a Python library
> routine in the presence of threads.  So a user can get burned by this
> through no fault of their own -- tempfile.TemporaryFile() is meant to be
> used by everyone, threads or not.

I don't know if tempfile.TemporaryFile() tickles teh bug every time or
not. I can say with confidence that the situation under NT is _no worse_
than windows 95 has always been. The race was introduced while moving
from win32 mutex's to CriticalSection's, for purely performance reasons.

Win32 Mutex's are _slow_. Critical sections made a huge difference - so
that's not going to be rolled backanytime soon. The correct solution
will come when we can solve the problem for win9x - we will ahve a
solution for NT.

I'm not advocating releasing
python-with-threading-that-may-tickle-this-bug or not releasing it - I
don't care either way. I'm simply trying to be clear about the
situation.

> > ...
> > By releasing a threaded Cygwin Python, more people will be able to
> > exercise Cygwin's pthreads support which will help test the
> > implementation.
> 
> If it's already known to be flawed, what's the point in having millions of
> users confirm it <wink>?

There are probably other bugs we don't know about. The
nearly-feature-complete pthread code base in cygwin is quite young, and
getting more exercise is a good thing. 

Rob
(Cygwin pthreads maintainer).


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -