Running multiple VM on one image

Peter Crowther Peter.Crowther at IT-IQ.com
Wed Dec 15 14:20:04 UTC 1999


> How do you solve access control
> problems and concurency (transaction...).

Access control via ACLs.  There was a comment on this list that capabilities
were a better way to go and don't require VM changes provided you lock out
certain primitives; having done this once with source-code restriction on
VisualWorks, I disagree and feel that VM changes are required as you cannot
lock out the primitives and still provide acceptable debugging.  I'm working
on this, but am stalled due to the current object header format.  I suspect
I won't be able to do much more until/unless Tim's NCM format gets merged
into the main development stream.  More details on request; I actually have
some design documentation on this!

Transactions are a pretty problem, and I'm still not entirely sure how to
solve this.  Current thinking is around the idea that I know something about
the application, or that the application is aware of transactions, and that
there is some active help as to what constitutes a transaction.  Concurrency
is solved more simply (but slowly) by semaphore-protecting write access to
instances*.  This is going to be messy as you end up with one semaphore per
instance.  I'm looking at subclassing Semaphore versus extending Object for
many of the application classes, and it's one area where being able to mix
in this 'critical region' functionality to the existing hierarchy would be a
real bonus.  Long-term, I think concurrency is also going to have to move
into the VM or be unreasonably slow.

> And what about preemptivness?

Image-level.  Once I have access control working, I can limit the priorities
of user-created Processes.  Then have a top-priority Process that does
timeslicing.

This is a bit of a brain dump, so my apologies if it is less than
crystal-clear.  I'd love to hear thoughts, comments, or [please!] requests
to collaborate on this!

		- Peter

* Yes, I know about dirty reads.  This is a first cut.





More information about the Squeak-dev mailing list