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.

Christian.