> 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
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
Functions declared in the following header files are not part
of the ABI:
- cellobject.h
- classobject.h
- code.h
- frameobject.h
- funcobject.h
- genobject.h
- pyarena.h
- pydebug.h
- symtable.h
- token.h
- traceback.h
>>> I don't th
The structure of type objects is not available to applications;
declaration of "static" type objects is not possible anymore
(for applications using this ABI).
>>> Hmm, that's going to create big problems for extensions that
>>> want to expose a C-API for their types: Type checks are
Martin v. Löwis wrote:
>> Now, with the PEP, I have a feeling that the Python C-API
>> will in effect be limited to what's in the PEP's idea of
>> a usable ABI and open up the non-inluded public C-APIs
>> to the same rate of change as the private APIs.
>
> That's certainly not the plan. Instead, t
Nick Coghlan wrote:
> M.-A. Lemburg wrote:
>> Now, with the PEP, I have a feeling that the Python C-API
>> will in effect be limited to what's in the PEP's idea of
>> a usable ABI and open up the non-inluded public C-APIs
>> to the same rate of change as the private APIs.
>
> Not really - before t
> Now, with the PEP, I have a feeling that the Python C-API
> will in effect be limited to what's in the PEP's idea of
> a usable ABI and open up the non-inluded public C-APIs
> to the same rate of change as the private APIs.
That's certainly not the plan. Instead, the plan is to have
a stable ABI
16 matches
Mail list logo
