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