Future of Pypy?

Ryan Stuart ryan.stuart.85 at gmail.com
Mon Feb 23 02:32:00 EST 2015


On Mon Feb 23 2015 at 4:15:42 PM Paul Rubin <no.email at nospam.invalid> wrote:
>
> What do you mean about Queues working with processes?  I meant
> Queue.Queue.  There is multiprocessing.Queue but that's much less
> capable, and it uses cumbersome IPC like pipes or sockets instead of a
> lighter weight lock.  Threads can also share read-only data and you can
> pass arbitrary objects (such as code callables that you want the other
> thread to execute--this is quite useful) through Queue.Queue.  I don't
> think you can do that with the multiprocessing module.
>

These things might be convenient but they are error prone for the reasons
pointed out. Also, the majority can be achieved via the process approach.
For example, using fork to take a copy of the current process (including
the heap) you want to use will give you access to any callables on the
heap.

The vital point here is that fork takes a *copy* of the process and runs in
a *separate* memory space. This means there can be no accidents here. If it
were to run in the same memory space like a thread then bugs anywhere in
the code you run could cause very nasty problems. This includes not only
bugs in your code, but also bugs in any other library code. Not only are
they nasty, they could be close to invisible.

And when I saw any code you run, I literally mean any. Even if you are
extra careful to not touch any shared state in your code, you can almost be
guaranteed that code higher up the stack, like malloc for example, *will*
be using shared state.

The risk of unintended and difficult to track issues when using threads is
very high because of shared state. Even if you aren't sharing state in your
code directly, code higher up the stack will be sharing state. That is the
whole point of a thread, that's what they were invented for. Using threads
safely might well be impossible much less verifiable. So when there are
other options that are just as viable/functional, result in far less risk
and are often much quicker to implement correctly, why wouldn't you use
them? If it were easy to use threads in a verifiably safe manner, then
there probably wouldn't be a GIL.

Cheers


> --
> https://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20150223/a35e1b3b/attachment.html>


More information about the Python-list mailing list