Stopping threads from the outside

G. Sumner Hayes sumner-nntp5 at forceovermass.com
Sun Mar 24 15:53:01 EST 2002


In article <3c9e2692$0$24819$e4fe514c at dreader3.news.xs4all.nl>, Boudewijn
Rempt wrote:
> Running each agent in its own process makes the system very 
> costly in terms of resources, makes it necessary for the agents
> to implement inter-process messaging. Not to mention them
> showing up individually in _top_...

Other than IPC, those are definitely not inherent differences between
threads and processes.  On many systems, processes aren't "very costly"
relative to threads, and on systems that implement threads in the "Plan
9 way" (rfork/sproc/clone on Plan 9/Irix/Linux) rather than the (IME,
broken) Solaris/Win32 way then the threads are likely to show up under
top anyway, though of course this depends on the version of top you're
using (and you can always use process groups and a top utility which
aggregates processes within those groups).

It's okay to worry about performance between threads and processes
as long as you realize that this is an implementation detail rather
than an architectural decision--i.e. measure and make sure it's
actually a performance problem before deciding it is.  The primary
factor in making an architectural choice between threads and processes
should be whether or not you want to share all memory (and I find it
useful to look at it from both sides--also consider "do I explicitly
_not_ want to have protected memory here?")

> That's the received opinion indeed. It still leads to problems.
> I mean -- it's why you can kill a process, but not a thread. But in
> an agent system, every agent (presumably running a thread, although
> I've implemented systems where agents share threads, cooperative
> multi-tasking agents) is on its own, and shouldn't own objects
> or locks.

The basic case sounds like a perfect candidate for muliple processes
to me.

  Sumner

-- 
rage, rage against the dying of the light

Usenet email address changes periodically.  sumner-nntp at forceovermass
period com is more permanent.



More information about the Python-list mailing list