I know I already posted some relevant threads to the other discussion,
but I wanted to point out a couple of specific comments on GIL
fairness from the discussion:
http://mail.python.org/pipermail/python-dev/2009-May/089752.html
http://mail.python.org/pipermail/python-dev/2009-May/089755.html
- P
I'd just like to point out some previous discussion about implementing
the GIL as a critical section or semaphore on Windows since it's come
up here (although not quite the center of the OP's proposal AFAICS):
http://bugs.python.org/issue6132
http://mail.python.org/pipermail/python-dev/2009-May/08
I'll do my best to try and explain/contribute, but please feel free to
correct anything I get wrong.
I believe the "swallowing" he's referring to is the ignoring of errno
EINTR. I don't think that's the correct place to handle signals to
begin with- why not just use the signal module to deal with
>> I question the whole notion of using open source in military weapons.
>> It seems like a rather basic violation of operational security. Perhaps
>> your enemies will exploit your bugs instead of nicely reporting them
>> and submitting patches on SourceForge ;-)
>
> Eric Raymond would argue that
> 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
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
> 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
> 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
> 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
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 scripting language and found
the PHP sources... unreadable ;)
Anyway, I'd like to ask something that may
10 matches
Mail list logo
