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
On Wed, May 27, 2009 at 4:24 AM, Nick Coghlan 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 a
first-come, f
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")
>
>
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]
> Includ
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
[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() ?
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
