Threads

[Terry Hancock]

Hi,
I'm writing a scheduler for running "behaviors" under a
system modelled roughly on "subsumption architectures"
(Dr. Rodney Brooks and others, check MIT's AI and Robotics
publications for references to "sumbsumption" and
"behavior programming").

Basically, it seems very reasonable to run these as
lightweight processes or "threads," so I'm considering
using the Python "pthreads" module for posix threading
in order to do this, but I've never done this before
and I have some concerns about it:

1) How broad is "pthreads" support? -- we have a goal
of this program running on at least Linux, Windows, and
Mac computers.  Will the code remain portable? What
platforms don't support pthreads?  Ultimately I'd
like to run this on embedded systems as well.

2) Do any of these architectures impose high per-thread
costs or limits on the number of processes that can be
running (or rather what are the limits I can expect for
any architecture?).  I ask this because this programming
model calls for large numbers (100s or 1000s) of very
light processes (e.g. 10 - 100 lines of Python code).

The alternative is to simply run the behaviors
sequentially, without spawning a bunch of separate
threads, but this is contrary to the design philosophy
of subsumption architectures, and loses some of their
advantages (e.g. "fail-soft" resistance to buggy
behavior code).  The idea is that programs consist
of large numbers of quasi-independent components which
can fail without wrecking the rest of the system.
Processes that "hang up" can just be killed by
the scheduler when they miss their deadlines.

Also, I'd just like to be aware of any caveats or
advice you might have about this kind of application.

Thanks a lot!

The project, BTW is http://light-princess.sourceforge.net/
this is for the "character agents".

-- 
Terry Hancock
hancock at earthlink.net