Interrput a thread

Jean-Paul Calderone calderone.jeanpaul at gmail.com
Mon Jan 3 17:24:55 EST 2011


On Jan 3, 4:17 pm, Adam Skutt <ask... at gmail.com> wrote:
> On Jan 3, 4:06 pm, Jean-Paul Calderone <calderone.jeanp... at gmail.com>
> wrote:
>
>
>
> > > Multiple processes, ok, but then regarding processes' interruption
> > > there will be the same problems pointed out by using threads?
>
> > No.  Processes can be terminated easily on all major platforms.  See
> > `os.kill`.
>
> Yes, but that's not the whole story, now is it?  It's certainly much
> more reliable and easier to kill a process.  It's not any easier to do
> it and retain defined behavior, depending on exactly what you're
> doing.  For example, if you kill it while it's in the middle of
> updating shared memory, you can potentially incur undefined behavior
> on the part of any process that can also access shared memory.

Then don't use shared memory.

>
> In short, taking a program that uses threads and shared state and
> simply replacing the threads with processes will likely not gain you a
> thing.  It entirely depends on what those threads are doing and how
> they do it.
>

Of course.  The whole point here is not about threads vs processes.
It's about shared memory concurrency vs non-shared memory
concurrency.  You can implement both with threads and both with
processes, but threads are geared towards shared memory and processes
are geared towards non-shared memory.  So what most people mean by
"use processes" is "don't use shared memory".

Jean-Paul



More information about the Python-list mailing list