Concurrency Proposal

[Tony Garnock-Jones]

Hi Levi,

Thanks for writing all this up.

The main comment I have is that I think we could get away with even
fewer VM changes than your proposal. For instance, all I/O could be
dealt with in userland. The current VM and image supports non-preemptive
thread switching, and userland code is part-written to implement
select()-based (which will have to become
MsgWaitForMultipleObjects()-based on win32, of course) I/O monitoring
and timeouts - it seems to me that with the single addition of a
timer-alarm interrupt to the VM, for preemption purposes, we could get
everything we need.

I do like the idea of switching whole threads in order to respond to an
interrupt - I'd been thinking more along the lines of trap handlers in
CPUs, just having a callback execute (although now, come to think of it,
the existence of the kernel stack is an implicit thread switch, isn't
it?), but I think the full context switch for interrupt handling is more
elegant.

Be warned that switching thread context requires winding some userland
state (the handler-stack, notably), and that a full context switch may
be awkward to engineer entirely on the VM level. Perhaps it's easier
simply to have a single callback userland subroutine run as an
interrupt, to allow the userland to switch itself out as appropriate.

Regarding the unix-specific details: Signals are incredibly evil! Which
sadly means that setitimer() and alarm() inherit the evilness. The main
problem is that there's just the one SIGALRM, and if a library you link
against happens to claim it, then you're just toast. (This has happened
to software I've been working on several times in my professional
career. Usually when linking against horrible telco libraries, but
that's by the by.)

My recommendation is to go for periodic sampling of gettimeofday(),
which at least is effectively reentrant. We don't have to call it every
bytecode - perhaps every 1000th bytecode, or only on branches, or similar.

Unfortunately, signals are more-or-less unavoidable in the long run:
we'll have to provide a decent interface to unix signals at some stage,
but I don't think the core preemption mechanism should be tied to that
interface.

Tony