On 9/17/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>
> Instead, the issue mainly died because nobody provided
> working code (along with a strategy on what to do with
> the existing extension modules).
>
When I first started writing python code I had just come out
of about 6 years of ker
On 9/17/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:32 PM 9/17/2005 -0400, Luis P Caamano wrote:
> >My point is that not yielding speedups on multiprocessors
> >and hurting performance on uniprocessors is not a good
> >or valid reason to drop free-threading.
>
> It is
No, it's not beca
Luis P Caamano wrote:
> Mind you though, I'm not trying to oversimplify the issue.
> I was not using python yet at that time (I started around
> 1.5/1.6) and I didn't see all the info involved in the decision
> making process, so I'm sure there were other issues that
> contributed to the decision o
At 12:32 PM 9/17/2005 -0400, Luis P Caamano wrote:
>My point is that not yielding speedups on multiprocessors
>and hurting performance on uniprocessors is not a good
>or valid reason to drop free-threading.
It is if you have only volunteers to maintain the code base, and the
changes significantly
On 9/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Message: 9
> Date: Fri, 16 Sep 2005 21:07:23 -0500
> From: [EMAIL PROTECTED]
> Subject: Re: [Python-Dev] Variant of removing GIL.
> Message-ID: <[EMAIL PROTECTED]>
>
>
> Martin> However, t
Martin> However, this is really hard to do correctly - if it were
Martin> simple, it would have been done long ago.
I don't believe difficulty is the only (or primary) barrier. I think
*someone* would have tackled it since Greg Stein did back in 1.4(?) or his
free-threading changes would
Sokolov Yura wrote:
> I think I know how to remove GIL Obviously I am an idiot.
Not an idiot, just lazy :-) Please try to implement your ideas,
and I predict that you will find:
1. it is a lot of work to implement
2. it requires changes to all C files, in particular to extension
modules out
Corrections:
Now, every thread keeps one n queue of objects to incref and second
queue to decref.
Both can be implemented as array, cause they will be freed at once.
Initially, every thread acquires GIL for "read".
Py_INCREF places a ref into a incref queue of a thread,
Py_DECREF places a ref in
Excuse my English.
I think I know how to remove GIL Obviously I am an idiot.
First about Py_INCREF and Py_DECREF.
We should not remove GIL at all. We should change it.
It must be "one writer-many reader" in a following semantic:
Lock has a "read-counter" and a "write-counter". Initially bo
