Cygwin Python -- Thread or not to thread...
Jason Tishler
Last week, I was about to release my next Cygwin Python distribution with
threading enabled for the first time. Although there is one known Cygwin
pthreads race condition that can cause a hang, this issue was not tickled
(so far) whenever I ran the regression for Python CVS. Unfortunately (or
fortunately depending on your perspective), while running the regression
test on Cygwin Python 2.1.1, test_threadedtempfile hung due to the above
mentioned problem.
So I am asking the Cygwin Python community the following:
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?
There are advantages and disadvantages to either choice. By releasing a
threaded Cygwin Python, more people will be able to exercise Cygwin's
pthreads support which will help test the implementation. This is
especially important on 9x/Me since I don't access to these platforms
and hence, have never personally tested Cygwin Python on them. The
downside is siccing a (buggy) threaded Cygwin Python on the general
public may result in significant heartache.
The more conservative approach is to continue to release Cygwin Python
with threading disabled until the known Cygwin pthreads issue is resolved.
Unfortunately, it maybe sometime before the race condition is prevented
(i.e., the fix is non-trivial):
http://www.cygwin.com/ml/cygwin-developers/2001-09/msg00438.html
So Cygwin Python users that need threading may have to continue to be
patience for an undetermined amount of time.
Please post your opinions instead of sending private email, so others
can see how a consensus (if any) was determined.
Thanks,
Jason
Robinow, David
That is, release your new version without threading.
Then follow it, as experimental, with the same thing, thread-enabled.
Tim Peters
> ...
> 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.
> ...
> 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>?
> ...
> The more conservative approach is to continue to release Cygwin Python
> with threading disabled until the known Cygwin pthreads issue is
> resolved.
AKA "the user-friendly" approach. Spell out in the README that users who
don't mind losing their hair are encouraged to build and test with thread
support enabled. A few will, most won't, and that's how it should be when
it's known to be buggy; the good news is that the few who do try it will be
much more likely to be motivated and helpful.
the-2.1.1-release-was-meant-to-be-rock-solid-ly y'rs - tim
g...@cs.unc.edu
then I'd say release with threads enabled. At least I get to try it
out. I get the choice insteading of having it made for me.
Thanks
gb
Robert Collins
> [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).
Tim Peters
> 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
> 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
Robert Collins
>
> 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.
k.
> 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.
Sounds to me like that is the appropriate mechanism to use under cygwin
as well. The caveats about not using win32 direct functions only apply
where other unix semantics and behaviour are still expected. The
Interlocked calls cannot block, and therefore will not interfere with
signals. They access process address space memory and will therefore
work with fork(). You may well need to reset the value after fork()
manually, as cygwin cannot do that for native win32 calls.
This is taking your assertion as face value :}... InterlockedXXX are
faster still than Criticalsections+win32 events (which is how condition
variables are emulated).
BTW: I am assuming that under linux condition variables are used - is
that correct?
Rob
Andy Todd
<mailman.1001431406...@python.org>:
>..that is the question.
>
>Last week, I was about to release my next Cygwin Python distribution with
>threading enabled for the first time. Although there is one known Cygwin
>pthreads race condition that can cause a hang, this issue was not tickled
>(so far) whenever I ran the regression for Python CVS. Unfortunately (or
>fortunately depending on your perspective), while running the regression
>test on Cygwin Python 2.1.1, test_threadedtempfile hung due to the above
>mentioned problem.
>
>So I am asking the Cygwin Python community the following:
>
> 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?
I'd say no. As more knowledgeable contributors have pointed out this isn't
an isolated issue and may cause unforseen problems. I'd stick with
disabling threads as a default for the time being.
>
[snip statement of problem and issues]
>
AFAIK it *is* possible to download the source package and make it on
cygwin, so perhaps this is the approach more adventurous users should use.
As cygwin auto selects and installs binary packages I would suggest these
should be as rock solid as possible.
Leave the bleeding edge stuff to those who are prepared to suffer the paper
cuts.
>
>Thanks,
>Jason
>
Regards,
Andy
--
Content free posts a speciality
Tim Peters
[Tim]
> 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.
[Robert Collins]
> Sounds to me like that is the appropriate mechanism to use under cygwin
> as well. The caveats about not using win32 direct functions only apply
> where other unix semantics and behaviour are still expected. The
> Interlocked calls cannot block, and therefore will not interfere with
> signals. They access process address space memory and will therefore
> work with fork().
I expect you'd have to examine the source for compatibility with what you're
doing to emulate signals and fork (which the native Win32 port ignores
entirely, for the obvious reason).
The InterlockedXXX stuff is a layer around Win32 CreateEvent +
WaitForSingleObject + (auto-reset) SetEvent, avoiding calls to the latter
two when there's no actual contention. InterlockedCompareExchange is
simulated with a kind of spin loop on Win95, which lacks that function.
That's about all there is to it.
> You may well need to reset the value after fork() manually, as cygwin
> cannot do that for native win32 calls.
The Python C API defines a PyOS_AfterFork() function, which platforms can
fill with whatever crud they need to do after a fork. On all platforms to
date, it calls (in both parent and child) PyEval_ReInitThreads(), and resets
the Python signal module's notion of what the current pid is. However,
mixing threads with fork is a frigging mess on the best of platforms, and it
generally takes a bona fide platform expert to guess what happens in the
end.
> This is taking your assertion as face value :}... InterlockedXXX are
> faster still than Criticalsections+win32 events (which is how condition
> variables are emulated).
>
> BTW: I am assuming that under linux condition variables are used - is
> that correct?
Yes, a Python lock under pthreads is implemented via a combination of a
flag, a pthread_mutex_t and pthread_cond_t.
Jason Tishler
> [Jason Tishler]
> > threading enabled? Or, should I continue to disabled threading
> > until the above known Cygwin pthreads issue is resolved?
Thanks to all that responded -- I appreciate your input, time, and help.
> > The more conservative approach is to continue to release Cygwin Python
> > with threading disabled until the known Cygwin pthreads issue is
> > resolved.
>
> AKA "the user-friendly" approach. Spell out in the README that users who
> don't mind losing their hair are encouraged to build and test with thread
> support enabled. A few will, most won't, and that's how it should be when
> it's known to be buggy; the good news is that the few who do try it will be
> much more likely to be motivated and helpful.
I will heed Tim's (and others) advice and continue to distribute Cygwin
Python *without* threading until all known Cygwin pthreads issues have
been resolved.
As a consolation prize, I offer the following enhancements to my Cygwin
Python distribution in lieu of threading:
_tkinter module
resource module
time.strftime fix
select.poll fix
Thanks,
Jason
Norman Vine
>
>I will heed Tim's (and others) advice and continue to distribute Cygwin
>Python *without* threading until all known Cygwin pthreads issues have
>been resolved.
>
>As a consolation prize, I offer the following enhancements to my Cygwin
>Python distribution in lieu of threading:
>
> _tkinter module
> resource module
> time.strftime fix
> select.poll fix
quite a prize :-))
FYI - I have managed to get the '_winreg' module working with Cygwin
< _winreg = Python access to the Windows Registry >
My current plan is to merge this into Jason's upcoming distribution
and then submit the necessary changes to the Python team in the hopes
of getting this included into the 'official' Python source tree.
This will be the most 'pervasive' Cygwin specific patch to the Python
source to date in that previously the Cygwin version has behaved
as a Posix only implementation whereas this patch requires knowledge of
the Win32 of doing things also.
Note as a side effect this opens up the possibility of exposing
additional Win32 API components to a Cygwin compiled Python.
Anyone interested in helping 'beta-test' this please contact me off list
Cheers
Norman Vine