Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.python
Subject: Re: Future of Pypy?
Date: Mon, 23 Feb 2015 20:40:40 -0800
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <87mw43apmf.fsf@jester.gateway.pace.com>
References: <jbijea5ph9m7sd9gqvp64ci1j708u5vkuq@4ax.com> <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> <mailman.19009.1424611670.18130.python-list@python.org> <pqrjeahei7v04lu0nqgsm01jrebj10hj8e@4ax.com> <mailman.19018.1424625741.18130.python-list@python.org> <87fv9xdb22.fsf@jester.gateway.pace.com> <54ea7ff4$0$12983$c3e8da3$5496439d@news.astraweb.com> <87zj85bcyu.fsf@jester.gateway.pace.com> <mailman.19048.1424661403.18130.python-list@python.org> <87lhjpb89i.fsf@jester.gateway.pace.com> <mailman.19052.1424664024.18130.python-list@python.org> <87h9udb1eq.fsf@jester.gateway.pace.com> <mailman.19058.1424676730.18130.python-list@python.org> <87bnkkb22u.fsf@jester.gateway.pace.com> <mailman.19110.1424737905.18130.python-list@python.org> <871tlgaxi7.fsf@jester.gateway.pace.com> <mailman.19113.1424743389.18130.python-list@python.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="0e072597111c5029870b25b8e5ee5406"; logging-data="25508"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ripDMABDaqVefTYo9blGm"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:1cwsgbnXtaUbCvkf/Nz1Xppwd3g= sha1:YDQnanptxa8CAnvmUHpKqfxIMb4=
Xref: csiph.com comp.lang.python:86291

Chris Angelico <rosuav@gmail.com> writes:

> So, you would have to pass code to the other process, probably. What
> about this:
> y = 4
> other_thread_queue.put(lambda x: x*y)

the y in the lambda is a free variable that's a reference to the
surrounding mutable context, so that's at best dubious.  You could use:

  other_thread_queue.put(lambda x, y=y: x*y)

> Or this:
>
> y = [4]
> def next_y():
>     y[0] += 1
>     return y[0]
> other_thread_queue.put(next_y)

There you have shared mutable data, which isn't allowed in this style.

> It may not be obvious with your squaring example, but every Python
> function has its context (module globals, etc). You can't pass a
> function around without also passing, or sharing, its data.

That is ok as long as the data can't change.

> With threads in a single process, this isn't a problem. They all
> access the same memory space, so they can all share state. As soon as
> you go to separate processes, these considerations become serious.

Right, that's a limitation of processes compared to threads.