Mail Archives: cygwin/2001/09/25/20:03:59
On Wed, 2001-09-26 at 09:50, Tim Peters wrote:
>
> 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
--
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 -