On Jan 3, 4:17 pm, Adam Skutt <ask...@gmail.com> wrote: > On Jan 3, 4:06 pm, Jean-Paul Calderone <calderone.jeanp...@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 -- http://mail.python.org/mailman/listinfo/python-list
