Mail Archives: cygwin/2001/09/26/00:37:54
[posted & mailed]
[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.
--
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 -