I've often thought of this.
The problem is that the GIL uses the regular python lock which has to be
non-recursive, since it is used for synchronization operations other than
mutual exclusion, e.g. one thread going to sleep, and another waking it up.
Now, we could easily create another class of
[PEP]
Function-like macros (in particular, field access macros) remain
available to applications, but get replaced by function calls
(unless their definition only refers to features of the ABI, such
as the various _Check macros)
[MAL]
Including Py_INCREF()/Py_DECREF() ?
[Nick]
I believe so -
Martin v. Löwis wrote:
No: fairness in mutex synchronization means that every waiter for the
mutex will eventually acquire it; it won't happen that one thread
starves waiting for the mutex. This is something that the mutex needs to
provide, not the application.
CriticalSections are first
Nick Coghlan wrote:
[PEP]
Function-like macros (in particular, field access macros) remain
available to applications, but get replaced by function calls
(unless their definition only refers to features of the ABI, such
as the various _Check macros)
[MAL]
Including Py_INCREF()/Py_DECREF() ?
On Tue, May 26, 2009, MRAB wrote:
p = re.compile(foo)
help(p.match)
Help on built-in function match:
match(...)
match(string[, pos[, endpos]]) -- match object or None.
Matches zero or more characters at the beginning of the string
p.match(string=foo)
Traceback (most recent
On Wed, May 27, 2009 at 4:24 AM, Nick Coghlan ncogh...@gmail.com wrote:
CriticalSections are first come first served on Windows, just like a
regular mutex.
Starting with Windows Server 2003 with Service Pack 1 (SP1), threads
waiting on a critical section do not acquire the critical section on
Heads up to those who were following, I did my best to clearly outline
the situation and direction in the tracker.
http://bugs.python.org/issue6132
It includes a patch that will break the expected behavior of the
thread lock object but make it possible to test GIL performance.
Note that for the
