Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #5617 > unrolled thread

Re: portable multiprocessing code

Started byIan Kelly <ian.g.kelly@gmail.com>
First post2011-05-17 15:18 -0600
Last post2011-05-17 15:18 -0600
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: portable multiprocessing code Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-17 15:18 -0600

#5617 — Re: portable multiprocessing code

FromIan Kelly <ian.g.kelly@gmail.com>
Date2011-05-17 15:18 -0600
SubjectRe: portable multiprocessing code
Message-ID<mailman.1716.1305667125.9059.python-list@python.org>
On Tue, May 17, 2011 at 9:14 AM, Eric Frederich
<eric.frederich@gmail.com> wrote:
> I have written some code using Python 2.7 but I'd like these scripts
> to be able to run on Red Hat 5's 2.4.3 version of Python which doesn't
> have multiprocessing.
> I can try to import multiprocessing and set a flag as to whether it is
> available.  Then I can create a Queue.Queue instead of a
> multiprocessing.Queue for the arg_queue and result_queue.
> Without actually trying this yet it seems like things would work okay
> except for the Worker class.  It seems I can conditionally replace
> multiprocessing.Queue with Queue.Queue, but is there anything to
> replace multiprocessing.Process with?

Yes, threading.Thread.

Pro: Since the multiprocessing module is designed to be a drop-in
replacement for the threading module, it should also be pretty
straight-forward to go in the reverse direction.

Con: You won't have true concurrency because of the GIL.

Cheers,
Ian

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web