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
> 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
> 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
> 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
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
> 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
>> 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
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'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 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
10 matches
Mail list logo
