Message: 1
Date: Tue, 9 Aug 2011 15:31:47 +0600
From: ? socketp...@gmail.com
To: python-dev@python.org
Subject: [Python-Dev] GIL removal question
Message-ID:
CAEmTpZGe2J6poDUW3sihHS3LHDdQ3cq5gWqfty_=z5w8r0r...@mail.gmail.com
Content-Type: text/plain; charset=UTF-8
On Wed, Aug 10, 2011 at 9:09 PM, David Beazley d...@dabeaz.com wrote:
You're forgetting step 5.
5. Put fine-grain locks around all reference counting operations (or rewrite
all of Python's memory management and garbage collection from scratch).
...
After implementing the aforementioned step
On Aug 10, 2011, at 6:15 AM, Nick Coghlan wrote:
On Wed, Aug 10, 2011 at 9:09 PM, David Beazley d...@dabeaz.com wrote:
You're forgetting step 5.
5. Put fine-grain locks around all reference counting operations (or rewrite
all of Python's memory management and garbage collection from
On Wed, Aug 10, 2011 at 7:32 AM, David Beazley d...@dabeaz.com wrote:
On Aug 10, 2011, at 6:15 AM, Nick Coghlan wrote:
On Wed, Aug 10, 2011 at 9:09 PM, David Beazley d...@dabeaz.com wrote:
You're forgetting step 5.
5. Put fine-grain locks around all reference counting operations (or
On Wed, Aug 10, 2011 at 1:43 PM, Guido van Rossum gu...@python.org wrote:
On Wed, Aug 10, 2011 at 7:32 AM, David Beazley d...@dabeaz.com wrote:
On Aug 10, 2011, at 6:15 AM, Nick Coghlan wrote:
On Wed, Aug 10, 2011 at 9:09 PM, David Beazley d...@dabeaz.com wrote:
You're forgetting step 5.
Removing GIL is interesting work and probably multiple people are willing to
contribute. Threading and synchronization is a deep topic and it might be
that if just one person toys around with removing GIL he might not see
performance improvement (not meaning to offend anyone who tried this,
On Wed, Aug 10, 2011 at 11:14, Vlad Riscutia riscutiav...@gmail.com wrote:
Removing GIL is interesting work and probably multiple people are willing
to contribute. Threading and synchronization is a deep topic and it might be
that if just one person toys around with removing GIL he might not
On Wed, Aug 10, 2011 at 10:19 AM, Brian Curtin brian.cur...@gmail.com wrote:
On Wed, Aug 10, 2011 at 11:14, Vlad Riscutia riscutiav...@gmail.com wrote:
Removing GIL is interesting work and probably multiple people are willing
to contribute. Threading and synchronization is a deep topic and it
On Aug 10, 2011, at 4:15 AM, Nick Coghlan wrote:
After implementing the aforementioned step 5, you will find that the
performance of everything, including the threaded code, will be quite a bit
worse. Frankly, this is probably the most significant obstacle to have any
kind of GIL-less
Now that we have concurrent.futures, is there any plan for multiprocessing
to follow suit? PEP 3148 mentions a hope to add or move things in the future
[0], which would be now.
[0] http://www.python.org/dev/peps/pep-3148/#naming
___
Python-Dev mailing
2011/8/10 Brian Curtin brian.cur...@gmail.com:
Now that we have concurrent.futures, is there any plan for multiprocessing
to follow suit? PEP 3148 mentions a hope to add or move things in the future
Is there some sort of concrete proposal? The PEP just seems to mention
it as an idea.
In
On Wed, Aug 10, 2011 at 7:19 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Aug 10, 2011, at 4:15 AM, Nick Coghlan wrote:
After implementing the aforementioned step 5, you will find that the
performance of everything, including the threaded code, will be quite a bit
worse.
Le Wed, 10 Aug 2011 14:54:33 -0500,
Benjamin Peterson benja...@python.org a écrit :
2011/8/10 Brian Curtin brian.cur...@gmail.com:
Now that we have concurrent.futures, is there any plan for
multiprocessing to follow suit? PEP 3148 mentions a hope to add or move
things in the future
Is
On Wed, Aug 10, 2011 at 15:36, Antoine Pitrou solip...@pitrou.net wrote:
Le Wed, 10 Aug 2011 14:54:33 -0500,
Benjamin Peterson benja...@python.org a écrit :
2011/8/10 Brian Curtin brian.cur...@gmail.com:
Now that we have concurrent.futures, is there any plan for
multiprocessing to
On Aug 10, 2011, at 1:36 PM, Antoine Pitrou wrote:
Le Wed, 10 Aug 2011 14:54:33 -0500,
Benjamin Peterson benja...@python.org a écrit :
2011/8/10 Brian Curtin brian.cur...@gmail.com:
Now that we have concurrent.futures, is there any plan for
multiprocessing to follow suit? PEP 3148 mentions
On 11/08/2011 0.02, Sandro Tosi wrote:
On Wed, Aug 10, 2011 at 21:55, Terry Reedytjre...@udel.edu wrote:
Latest version of the `heapq Python source code
-http://svn.python.org/view/python/branches/release27-maint/Lib/heapq.py?view=markup`_
On Wed, Aug 10, 2011 at 4:45 PM, Brian Curtin brian.cur...@gmail.com wrote:
On Wed, Aug 10, 2011 at 15:36, Antoine Pitrou solip...@pitrou.net wrote:
Le Wed, 10 Aug 2011 14:54:33 -0500,
Benjamin Peterson benja...@python.org a écrit :
2011/8/10 Brian Curtin brian.cur...@gmail.com:
Now that
2011/8/10 Raymond Hettinger raymond.hettin...@gmail.com:
On Aug 10, 2011, at 1:36 PM, Antoine Pitrou wrote:
Le Wed, 10 Aug 2011 14:54:33 -0500,
Benjamin Peterson benja...@python.org a écrit :
2011/8/10 Brian Curtin brian.cur...@gmail.com:
Now that we have concurrent.futures, is there any
On Thu, Aug 11, 2011 at 4:55 AM, Brian Curtin brian.cur...@gmail.com wrote:
Now that we have concurrent.futures, is there any plan for multiprocessing
to follow suit? PEP 3148 mentions a hope to add or move things in the future
[0], which would be now.
As Jesse said, moving multiprocessing or
On Wed, Aug 10, 2011 at 11:58:24PM +0300, Ezio Melotti wrote:
hg.python.org/cpython/2.7/path/to/file.py should work just fine.
The correct path seems to be:
http://hg.python.org/cpython/file/2.7/Lib/modulefile.py
IIRC the reason why we don't do it on 2.x is because we don't have
the
20 matches
Mail list logo
