> Cheers,
>
> Kristján
>
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> [mailto:python-dev-bounces+kristjan=ccpgames....@python.org] On Behalf Of
> Phillip Sitbon
> Sent: 27. maí 2009 22:23
> To: python-dev
> Subject: Re: [Py
rg
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
Phillip Sitbon
Sent: 27. maí 2009 22:23
To: python-dev
Subject: Re: [Python-Dev] Making the GIL faster & lighter on Windows
If I'm not mistaken, calling InitializeCriticalSection rather than
InitializeCritic
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
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
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
> 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.
Right, I guess I was thinking of it in terms of nee
>> According to a past discussion on this list, the current implementation
>> isn't:
>> http://mail.python.org/pipermail/python-dev/2008-March/077814.html
>> (at least on the poster's system)
>>
>
> I believe he's only talking about Linux. Apples & oranges when it
> comes to stuff like this
Plea
> If you define fairness in this context as not starving other threads
> while consuming resources, that is built into the interpreter via
> sys.setcheckinterval() and also anywhere the GIL is released for I/O.
> What might be interesting is to see if releasing a critical section
> and immediately
> FWIW, Win32 CriticalSections are guaranteed to be fair, but they don't
> guarantee a defined order of wakeup among threads of equal priority.
Indeed, I should have quoted the MSDN docs:
"The threads of a single process can use a critical section object for
mutual-exclusion synchronization. Ther
Martin v. Löwis v.loewis.de> writes:
>
> What about fairness? I don't know off-hand whether the GIL is
> fair,
According to a past discussion on this list, the current implementation isn't:
http://mail.python.org/pipermail/python-dev/2008-March/077814.html
(at least on the poster's system)
Rega
On Tue, May 26, 2009 at 16:07, "Martin v. Löwis" wrote:
>> 3. ?? - I'm sure there are other issues that deserve a look.
>
> What about fairness? I don't know off-hand whether the GIL is
> fair, or whether critical sections are fair, but it needs to be
> considered.
FWIW, Win32 CriticalSections ar
> You should definitely open a bug entry in http://bugs.python.org. There, post
> your patch, some explanations and preferably a quick way (e.g. a simple
> script)
> of reproducing the speedups (without having to install a third-party library
> or
> extension, that is).
I'll get started on that
> 3. ?? - I'm sure there are other issues that deserve a look.
What about fairness? I don't know off-hand whether the GIL is
fair, or whether critical sections are fair, but it needs to be
considered.
Regards,
Martin
___
Python-Dev mailing list
Python-D
On approximately 5/26/2009 12:48 PM, came the following characters from
the keyboard of Phillip Sitbon:
Hi everyone,
I'm new to the list but I've been embedding Python and working very
closely with the core sources for many years now. I discovered Python
a long time ago when I needed to embed a
Hello,
> Hopefully I haven't wasted anyone's time - I just wanted to share what
> I see as a possibly substantial improvement to Python's core. let me
> know if you're interested in a patch to use for your own testing.
You should definitely open a bug entry in http://bugs.python.org. There, post
16 matches
Mail list logo
