Re: [Python-Dev] GIL removal question

2011-08-17 Thread Sturla Molden

Den 10.08.2011 13:43, skrev Guido van Rossum:

They have a specific plan, based on Software Transactional Memory:
http://morepypy.blogspot.com/2011/06/global-interpreter-lock-or-how-to-kill.html



Microsoft's experiment to use STM in .NET failed though. And Linux got 
rid of the BKL without STM.


There is a similar but simpler paradim called "bulk synchronous 
parallel" (BSP) which might work too. Threads work independently for a 
particular amount of time with private objects (e.g. copy-on-write 
memory), then enter a barrier, changes to global objects are 
synchronized and the GC collects garbage, after which worker threads 
leave the barrier, and the cycle repeats.


To communicate changes to shared objects between synchronization 
barriers, Python code must use explicit locks and flush statements. But 
for the C code in the interpreter, BSP should give the same atomicity 
for Python bytecodes as the GIL  (there is just one active thread inside 
the barrier).


BSP is much simpler to implement than STM because of the barrier 
synchronization. BSP also cannot deadlock or livelock. And because 
threads in BSP work with private memory, there will be no trashing 
(false sharing) from the reference counting GC.


Sturla




___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Packaging in Python 2 anyone ?

2011-08-17 Thread Vinay Sajip
Tarek Ziadé  gmail.com> writes:

> IOW, the task to do is:
> 
> 1/ copy packaging and all its stdlib dependencies in a standalone project
> 2/ rename packaging to distutils2
> 3/ make it work under older 2.x and 3.x (2.x would be the priority)  <
> 4/ release it, promote its usage
> 5/ consolidate the API with the feedback received
> 
> I realize it's by far the less interesting task to do in packaging,
> but it's by far one of the most important

Okay, I had a bit of spare time today, and here's as far as I've got:

Step 1 - done.
Step 2 - done.
Step 3 - On Python 2.6 most of the tests pass:

Ran 322 tests in 12.148s

FAILED (failures=3, errors=4, skipped=39)

See the detailed test results (for Linux) at https://gist.github.com/1152791

The code is at https://bitbucket.org/vinay.sajip/du2/

stdlib dependency code is either moved to util.py or test/support.py as
appropriate. You need to test in a virtualenv with unittest2 installed. No work
has been done on packaging the project.

I'm not sure if I'll have much more time to spend on this, but it's there in
case someone else can look at the remaining test failures, plus Steps 4 and 5;
hopefully I've broken the back of it :-)

Regards,

Vinay Sajip


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Packaging in Python 2 anyone ?

2011-08-17 Thread Chris McDonough
I'll throw this out there.. why is it going to have a different name on
python2 than on python3?

- C

On Wed, 2011-08-17 at 22:30 +, Vinay Sajip wrote:
> Tarek Ziadé  gmail.com> writes:
> 
> > IOW, the task to do is:
> > 
> > 1/ copy packaging and all its stdlib dependencies in a standalone project
> > 2/ rename packaging to distutils2
> > 3/ make it work under older 2.x and 3.x (2.x would be the priority)  <
> > 4/ release it, promote its usage
> > 5/ consolidate the API with the feedback received
> > 
> > I realize it's by far the less interesting task to do in packaging,
> > but it's by far one of the most important
> 
> Okay, I had a bit of spare time today, and here's as far as I've got:
> 
> Step 1 - done.
> Step 2 - done.
> Step 3 - On Python 2.6 most of the tests pass:
> 
> Ran 322 tests in 12.148s
> 
> FAILED (failures=3, errors=4, skipped=39)
> 
> See the detailed test results (for Linux) at https://gist.github.com/1152791
> 
> The code is at https://bitbucket.org/vinay.sajip/du2/
> 
> stdlib dependency code is either moved to util.py or test/support.py as
> appropriate. You need to test in a virtualenv with unittest2 installed. No 
> work
> has been done on packaging the project.
> 
> I'm not sure if I'll have much more time to spend on this, but it's there in
> case someone else can look at the remaining test failures, plus Steps 4 and 5;
> hopefully I've broken the back of it :-)
> 
> Regards,
> 
> Vinay Sajip
> 
> 
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/lists%40plope.com


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Packaging in Python 2 anyone ?

2011-08-17 Thread Fred Drake
On Wed, Aug 17, 2011 at 9:15 PM, Chris McDonough  wrote:
> I'll throw this out there.. why is it going to have a different name on
> python2 than on python3?

So it can be a drop-in replacement for the existing distutils2, I'd expect.

"packaging" is new with Python3, and is the Guido-approved name.


  -Fred

-- 
Fred L. Drake, Jr.    
"A person who won't read has no advantage over one who can't read."
   --Samuel Langhorne Clemens
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Packaging in Python 2 anyone ?

2011-08-17 Thread Nick Coghlan
On Thu, Aug 18, 2011 at 12:15 PM, Fred Drake  wrote:
> On Wed, Aug 17, 2011 at 9:15 PM, Chris McDonough  wrote:
>> I'll throw this out there.. why is it going to have a different name on
>> python2 than on python3?
>
> So it can be a drop-in replacement for the existing distutils2, I'd expect.
>
> "packaging" is new with Python3, and is the Guido-approved name.

It's actually for the same reason that unittest changes are backported
under the unittest2 name - the distutils2 name can be used in the
future to get Python 3.4 packaging features in Python 3.3, but that
would be difficult if the backport shadowed the standard library name.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Packaging in Python 2 anyone ?

2011-08-17 Thread Fred Drake
On Wed, Aug 17, 2011 at 11:00 PM, Nick Coghlan  wrote:
> It's actually for the same reason that unittest changes are backported
> under the unittest2 name - the distutils2 name can be used in the
> future to get Python 3.4 packaging features in Python 3.3, but that
> would be difficult if the backport shadowed the standard library name.

Ah, yes... the old "too bad we stuck it in the standard library" problem.

For some things, an easy lament, but for foundational packaging-related
things, it's hard to get around.


  -Fred

-- 
Fred L. Drake, Jr.    
"A person who won't read has no advantage over one who can't read."
   --Samuel Langhorne Clemens
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com