Concurrency Proposal

[Brian Rice]

Hey Tony. Thanks for the comments.

On Mar 14, 2006, at 9:38 AM, Tony Garnock-Jones wrote:

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

That's (all of it) worth some thought, thanks!

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

This is an interesting scaling problem, sure. We'll still need the  
option of handling posix signals for more mundane situations, for  
different purposes, e.g. SIGHUP, SIGINT, etc. Obviously with this  
kind of library-override possibility, the signal-handling behavior  
shouldn't be absolutely mandatory. I'm thinking of our smart-console  
library in plugins/ that wraps ncurses - I would bet that the  
problems with that setup related to signal-handler issues. Maybe we  
can fix that with some insight in this direction.

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

Either that or an internal millisecond timer... I forget how Squeak  
does it, though.

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

Indeed.

--
-Brian
http://tunes.org/~water/brice.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060314/914bffba/PGP.pgp