Concurrency Proposal

[Levi Pearson]

On Mar 14, 2006, at 10:38 AM, Tony Garnock-Jones wrote:
>
> Hi Levi,
>
> Thanks for writing all this up.
>

Thanks for your response!

> 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.

It may be possible to do all the I/O in userland, and I'll have to
take a look at the mechanisms you mention.  I liked the idea of the vm
providing the synchronous I/O abstraction and having it integrated
with the interrupt concept, though.  I'll do some thinking to see if I
can come up with any real defense for it.


> 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.


Can you give me some references to where this userland state is? I
don't remember seeing the current support for switching threads, so a
reference to that would be helpful too.

> 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.


I really wish there was a better way to get pinged periodically by the
OS.  Polling via a context switch to kernel space at frequent
intervals seems pretty evil, too, but if you guys prefer that to the
possibility of future signal collisions with libraries, I'll plan on
doing it that way.

> 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.

This should be fairly easy to integrate into the general interrupt
framework, at least for signals we want to trigger Slate handlers for.

		--Levi