Cygwin Python -- Thread or not to thread...

Tue Sep 25 16:50:00 GMT 2001

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