[gambit-list] Termite SMP shortcuts?

Christian Jaeger christian at pflanze.mine.nu
Thu Apr 19 17:27:39 EDT 2007

Phil Dawes wrote:
> Hi All,
> I was just wondering, given the shared-nothing nature of the termite 
> process model are there any shortcuts that could be taken to get termite 
> running SMP? (as apposed to developing a fully fledged SMP gambit).

(I haven't tried Termite yet, but from what I've read I think it should
already be possible to start multiple Gambit instances with Termite
communicating with others. That's why continuation serialization has
been done after all :-).)
> E.g. maybe running multiple runtimes in the same process but each with 
> separate managed heaps so that the GC doesn't have to worry too much 
> about locking?

Why do you want the multiple runtimes to all be in the same OS process?
I guess you think that's faster, but I can only think of two things
making this faster, (a) that the OS could switch between two threads in
the same process significantly faster than between two processes, (b)
that you would pass data over shared memory instead of the write/read
system calls. One could still implement b with processes (e.g. using
mmap'ed files). The advantage of separate processes is stability, if one
crashes the others can still continue to work (and could restart the
crashed process, for example). This seems especially important as Gambit
allows so easy integration with C (and so easy hacking with unsafe
internals :), so crashes are rather common.

I've read up a bit lately on Erlang, and apart from the "fail early, and
anticipate failures" one idea hooked into my brain: that of security by
safe naming (one Erlang process can send messages to another one if and
only if it knows it's name, and it can pass on this name to others). I
imagine a framework for Erlang style work where I have the full power of
Gambit at hands for coding applications; using the full Gambit stuff,
there's nothing preventing hijacking other threads in the same process.
(Does Termite guarantee security? I don't think this is an easy task if
the offered language isn't to be very limited. I remember PHP people
telling me years ago "we have a secure infrastructure where multiple
websites/users can safely run in the same OS user/processes" as argument
against mod_perl, but from what I gather there have been many holes in
that implementation, and still it is too limited for many PHP
applications and has to be switched off (correct?, or only part of it?
not sure).) So I'd say it's probably wiser to use the OS security
mechanisms (reuse existing safety, have more features with less work).
There are two of them: (1) use separate processes with separate userid's
for each of them, possibly sequentially supplied from a range by an uid
server which is running as root (and either forks off children on demand
like the unix "login" process, or uses the sendmsg/recvmsg SO_PASSCRED
mechanism on unix sockets); I'm missing a way to safely determine
whether any particular temporary uid is still in use, though (on linux,
haven't looked close enough yet, maybe ptrace could do); (2) on linux,
you can chroot to a safe place without writable store, setuid and switch
off dumpability/tracability (with prctl(2)), after which processes of
even the same uid shouldn't be able to get at the data of each other
(they can still kill each other, though). (Actually I'm playing a bit
with those approaches right now, I've extended my cj-posix module for this.)

It would be interesting seeing a framework to create Erlang style
applications where each process is really securely separated (as much as
the OS can secure users from each other), kind of like Unix chroot/uid
based security (and in fact using that underneath) but much easier to
work with. Of course Erlang (and also Marc with Gambit's threading) have
implemented userspace threading for some reason (efficiency..); the
Linux scheduler is said to be very good today, though. But ok, if you
really need a million threads and need each of them only take up 1kB at
most so it all fits into 1G, OS threads might not work (with a page size
of 4kB already :), and OS processes will surely have another magnitude
bigger memory requirements. What I'm not sure is (1) how often you need
a million Erlang/Termite style processes in practical work, (2) whether
it would be feasible to choose which Termite processes can
securely/safely reside in the same Gambit runtime and which ones can't;
maybe simply declaring whether a new child has to be safely separated
(or into which "domain" it is to be separated) is enough for this (a
little less simple than Erlang but maybe still managable). For example
for a web application, it would be enough to have one securely separated
process for each logged in user currently having requests pending (and
some additional waiting time before tearing down processes, to prevent
too frequent forking). This involves more frequent forking than apache 1
did, but there may be less parallel OS processes than apache 1 needed
(because multiple connections of the same authenticated user can be
safely handled by the same Gambit process, and on top of that: how many
of your visitors are authenticated, *and* how many requests of the
authenticated ones need to carry out sensitive work?). So maybe using OS
security could work out fine.


More information about the Gambit-list mailing list