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

[Tim Peters]

[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