Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com From: "Tim Peters" To: "Cygwin" , "Python-List" Subject: RE: Cygwin Python -- Thread or not to thread... Date: Tue, 25 Sep 2001 19:50:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <1001456201.7752.12.camel@lifelesswks> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal [Robert Collins] > 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 back anytime soon. The correct solution > will come when we can solve the problem for win9x - we will ahve a > solution for NT. 1. Python exposes, and uses internally, exactly one synchronization primitive, a "Python lock" (basically an unowned non-reentrant lock). Everything else builds on that. TemporaryFile() isn't special in any respect -- if it's broken, all uses of Python locks are likely just as broken, and that's every lock used for every purpose in the code base. test_threadedtempfile is simply a stress test of that mechanism in one particular context, and it's tested in that context because it's particularly easy to characterize failure modes there. 2. See Include/thread_nt.h in the Python source distribution for the native Windows "Python lock" support. It uses the Win32 InterlockedXXX APIs, not Mutex or even CriticalSection. It's very efficient (but it's not trying to emulate pthreads, just Python locks), has been used in high-stress contexts for years on all flavors of Windows, and has no known (or even suspected) bugs. > I'm not advocating releasing python-with-threading-that-may-tickle- > this-bug The rub is that "this bug" is in the only synch primitive Python has (the C semaphore code you may have seen is an unused historical artifact). > or not releasing it - I don't care either way. I'm simply trying to be > clear about the situation. > ... > 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. That fits my defn of an alpha release. If it's made clear to Cygwin users that a threaded Python there isn't yet production quality, fine. It doesn't sound like a reasonable default to me, though: Python 2.1.1 was supposed to be an ultra-stable pure bugfix release. Experimental code is surely necessary, but shouldn't come with a "2.1.1" label attached. give-threads-a-bad-name-in-a-stable-release-and-we-all-get-black- eyes-ly y'rs - tim -- 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/