Mail Archives: cygwin/2001/09/25/19:51:18
[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/
- Raw text -