On Sat, Aug 27, 2011 at 2:59 AM, Ask Solem a...@celeryproject.org wrote:
On 26 Aug 2011, at 16:53, Antoine Pitrou wrote:
Hi,
I think that deprecating the use of threads w/ multiprocessing - or
at least crippling it is the wrong answer. Multiprocessing needs the
helper threads it
+3 (agreed to Jesse, Antoine and Ask here).
The http://bugs.python.org/issue8713 described non-fork implementation
that always uses subprocesses rather than plain forked processes is the
right way forward for multiprocessing.
I see two drawbacks:
- it will be slower, since the interpreter
2011/8/29 Charles-François Natali neolo...@free.fr:
+3 (agreed to Jesse, Antoine and Ask here).
The http://bugs.python.org/issue8713 described non-fork implementation
that always uses subprocesses rather than plain forked processes is the
right way forward for multiprocessing.
I see two
On Mon, 29 Aug 2011 13:03:53 -0400
Jesse Noller jnol...@gmail.com wrote:
2011/8/29 Charles-François Natali neolo...@free.fr:
+3 (agreed to Jesse, Antoine and Ask here).
The http://bugs.python.org/issue8713 described non-fork implementation
that always uses subprocesses rather than plain
On Mon, Aug 29, 2011 at 1:16 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 29 Aug 2011 13:03:53 -0400
Jesse Noller jnol...@gmail.com wrote:
2011/8/29 Charles-François Natali neolo...@free.fr:
+3 (agreed to Jesse, Antoine and Ask here).
The http://bugs.python.org/issue8713 described
Le lundi 29 août 2011 à 13:23 -0400, Jesse Noller a écrit :
Yes, it is annoying; but again - this makes it more consistent with
the windows implementation. I'd rather that restriction than the
sanitization of the ability to use threading and multiprocessing
alongside one another.
That
On Mon, Aug 29, 2011 at 1:22 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le lundi 29 août 2011 à 13:23 -0400, Jesse Noller a écrit :
Yes, it is annoying; but again - this makes it more consistent with
the windows implementation. I'd rather that restriction than the
sanitization of the
On Mon, Aug 29, 2011 at 8:16 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 29 Aug 2011 13:03:53 -0400 Jesse Noller jnol...@gmail.com wrote:
Yes; but spawning and forking are both slow to begin with - it's
documented (I hope heavily enough) that you should spawn
multiprocessing
On Mon, Aug 29, 2011 at 8:42 PM, Jesse Noller jnol...@gmail.com wrote:
On Mon, Aug 29, 2011 at 1:22 PM, Antoine Pitrou solip...@pitrou.net wrote:
That sanitization is generally useful, though. For example if you want
to use any I/O after a fork().
Oh! I don't disagree; I'm just against the
On 8/29/2011 3:41 PM, Nir Aides wrote:
I am not familiar with the python-dev definition for deprecation, but
Possible to planned eventual removal
when I used the word in the bug discussion I meant to advertize to
users that they should not mix threading and forking since that mix is
and
On 26 Aug 2011, at 16:53, Antoine Pitrou wrote:
Hi,
I think that deprecating the use of threads w/ multiprocessing - or
at least crippling it is the wrong answer. Multiprocessing needs the
helper threads it uses internally to manage queues, etc. Removing that
ability would require a
Another face of the discussion is about whether to deprecate the mixing of
the threading and processing modules and what to do about the
multiprocessing module which is implemented with worker threads.
On Tue, Aug 23, 2011 at 11:29 PM, Antoine Pitrou solip...@pitrou.netwrote:
Le mardi 23 août
On Fri, Aug 26, 2011 at 3:18 AM, Nir Aides n...@winpdb.org wrote:
Another face of the discussion is about whether to deprecate the mixing of
the threading and processing modules and what to do about the
multiprocessing module which is implemented with worker threads.
There's a bug open -
Hi,
I think that deprecating the use of threads w/ multiprocessing - or
at least crippling it is the wrong answer. Multiprocessing needs the
helper threads it uses internally to manage queues, etc. Removing that
ability would require a near-total rewrite, which is just a
non-starter.
I
Hi all,
Please consider this invitation to stick your head into an interesting
problem:
http://bugs.python.org/issue6721
Nir
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
2011/8/23, Nir Aides n...@winpdb.org:
Hi all,
Hello Nir,
Please consider this invitation to stick your head into an interesting
problem:
http://bugs.python.org/issue6721
Just for the record, I'm now in favor of the atfork mechanism. It
won't solve the problem for I/O locks, but it'll at
On Tue, 23 Aug 2011 20:43:25 +0200
Charles-François Natali cf.nat...@gmail.com wrote:
Please consider this invitation to stick your head into an interesting
problem:
http://bugs.python.org/issue6721
Just for the record, I'm now in favor of the atfork mechanism. It
won't solve the problem
2011/8/23 Antoine Pitrou solip...@pitrou.net:
Well, I would consider the I/O locks the most glaring problem. Right
now, your program can freeze if you happen to do a fork() while e.g.
the stderr lock is taken by another thread (which is quite common when
debugging).
Indeed.
To solve this, a
Le mardi 23 août 2011 à 22:07 +0200, Charles-François Natali a écrit :
2011/8/23 Antoine Pitrou solip...@pitrou.net:
Well, I would consider the I/O locks the most glaring problem. Right
now, your program can freeze if you happen to do a fork() while e.g.
the stderr lock is taken by another
19 matches
Mail list logo
