Squeak-e

squeak-e@lists.squeakfoundation.org

54 discussions

Sagan security model
by Cees de Groot 28 Mar '03

28 Mar '03

[for want of a better place I post this here] With OmniBase finally available under Squeak (/me pats: self on: shoulder), I've started work on the content management system (and more) that will, hopefully, run my cdegroot.com website some time this century. For now, there's some marginal information on http://swiki.squeakfoundation.org/sea/66 - it's still too much vapourware to start a website for. Anyway, if you read the design note on http://swiki.squeakfoundation.org/sea/75, you will notice that I'm planning to make Sagan completely free of ACL's. And as I don't want to make the mistake of slapping security on as an afterthought, I'd like to sollicit any ideas before commencing work on this layer. The basic idea I have is that you are always known to the system as a user - where most users will all start out sharing the same 'anonymous' user, with a sort of 'copy-on-write' mechanism creating a private set of capabilities as soon as the user gets new capabilities. The capabilities are kept server-side, the user can access them by authenticating (by whatever means - probably I'll start out with a cleartext password on an unsecured connection ;-)). Capabilities are persisted, of course, in OmniBase. Ideally(?), there would be a mesh of capabilities between the m users and the n objects to protect. However, I fear that this m*n number may be a tad unmanagable for, say, 1000 users and 10,000 protectable objects. So, the first thing I'm looking for is ways to lower this count, maybe by grouping objects in some way and handing out a single capability to them, etcetera. Questions to be answered: can this be done without impairing either security or user-friendliness? If yes, what is a good basis for this grouping? The second issue, more down-to-earth, is how to implement capabilities. On an object with n methods, you can theoretically hand out n -- \ (n) / (k) -- k=1 different capabilities ("\[\sum_{k=1}^{n} \left( \begin{array}{c}n \\ k \end{array} \right)\]" if you're into LaTeX). That's a tad high to resolve with static classes. So some sort of dynamic wrapper must be made to represent capabilities, and it must be lightweight and space efficient, because Sagan is going to store lots of them. I had a third issue, but an incoming phone call popped that off the stack.

1 0

Notice of New Thread
by Mark S. Miller 21 Mar '03

21 Mar '03

The Usenix Security 2003 Conference rejected our paper, "Capability Myths Demolished" http://zesty.ca/capmyths/usenix.pdf . The rejection is posted at http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html , which is also the root of a thread at which we'll be discussing our failure to convince, and what we should do about it. If you're interested, please read the thread and join the discussion. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

RE: [Squeak-e] Islands image has been retrieved
by Withers, Robert 14 Mar '03

14 Mar '03

Yay! That's awesome news, Lex. Rob > -----Original Message----- > From: Lex Spoon [mailto:lex@cc.gatech.edu] > Sent: Friday, March 14, 2003 4:59 AM > To: The general-purpose Squeak developers list > Cc: squeak-e(a)lists.squeakfoundation.org > Subject: [Squeak-e] Islands image has been retrieved > > > > Okay, a very kind soul has obtained my old files from a Disney backup > archive. You can now download a pre-loaded Islands image as > well as an > interp.c that has the necessary primitive changes. Look for > "lex-sandbox.zip" on: > > http://minnow.cc.gatech.edu/squeak/2074 > > > Lex Spoon > _______________________________________________ > Squeak-e mailing list > Squeak-e(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeak-e >

1 0

Islands image has been retrieved
by Lex Spoon 14 Mar '03

14 Mar '03

Okay, a very kind soul has obtained my old files from a Disney backup archive. You can now download a pre-loaded Islands image as well as an interp.c that has the necessary primitive changes. Look for "lex-sandbox.zip" on: http://minnow.cc.gatech.edu/squeak/2074 Lex Spoon

2 1

RE: [Squeak-e] adding eventual sending to Croquet's ScriptProcess and ScriptScheduler
by Withers, Robert 18 Feb '03

18 Feb '03

Andreas, I said: > -----Original Message----- > From: Withers, Robert [mailto:rwithers@quallaby.com] > I am curious about your use the ivar #myQueue in the ScriptProcess. I > really like that your ScriptProcess will compute a value, and > that that > value is the 'result' of the process. That's a very standard view of > computations. Isn't it a functional view? A better approach > for supporting > eventual sending may be to have a subclass of ScriptProcess > which holds the > continuation to the invocation site. Actually, I am now thinking that a subclass may not be needed, since ScriptProcess already holds onto the invoking message (AsyncScriptMessageSend to be replaced by EventualScriptMessageSend for eventual sending) and the owner, which is the same object. There are also the ivars #myHandler and #myEventMap. In the following method, called when the Process returns from the last stack frame, there are three different mechanisms that we could hook into to activate the resolver. ScriptProcess>>#stopScriptProcess: result ... owner ifNotNil:[owner scriptStopped: self]. myHandler ifNotNil:[myHandler releaseTo: nil]. myEventMap ifNotNil:[self signal: #done with: resultObj]. - owner is the ScriptMessageSend, so an implementation of #scriptStopped: in the EventualScriptMessageSend, could activate the resolver. - myHandler is set when sending #observe: and it is an EventObserver. Currently this only looks to be used by the #waitUntil protocols and it blocks on a semaphore. I suppose that a special observer could be created that holds the resolver. - myEventMap holds event registrations. These can be set at a low-level with #on:notify: or at a higher level by startScript:when:. So after the EventualScriptMessageSend is converted to a ScriptProcess, a registration of the following could wake up the resolver proc on: #done notify: (#resolve: asAsyncScriptMessageIn: self resolver arguments: #()) What do you think would be the best way to activate the resolver? cheers, rob

3 12

eventual references and promises. What's an alternate compiler solution to deal with promise continuations?
by Robert Withers 16 Feb '03

16 Feb '03

Hi All, Does the rubber band nature of eventual message sending, especially now that #immediateRef is working, help provide an interesting interface for users? I don't know if people are aware of the way I adopted Mark's E eventual sending. This is especially true since I really haven't written any documentation on it. :( Here's an attempt at an introduction to them: From reading ( http://www.erights.org/elib/concurrency/msg-passing.html ), I got very excited. In E, with specialized syntax, an expression like "person <- computeCreditRating()" would eventually send the message and immediately return a promise for the result. This promise will 'become' the result of the eventual send. This requires a promise continuation to be sent with the message, so that the evaluation will resolve the promise. Before that happens, your subsequent code can send messages to the promise or the original eventual reference. There are special messages that you can send to synchronize with the result. There is a way to write code that waits until a set of promises are resolved, before doing further work. This allows you to synchronize the results. To try this I decided that building a trampoline that you could send messages to as a surrogate to the real object would allow us to trigger eventual sending just by slightly changing the sending context. This sending context was scoped to that object reference that built the context for you, when you sent #eventualRef to the object reference that will be your receiver. This way, we don't need special syntax to invoke eventual messages. The machinery of ScriptScheduler and ScriptProcess, allows an implementation of #immediateRef to work. This is the first step toward adding the synchronization features. The next step would be to synchronize multiple promises, but I don't have a solution in mind, yet. Anyone have an idea? [Context implementation] I also want to discuss how to improve my contexts. Maybe it is possible to have a perfectly contained reference to an object and use #dnu and a special class for promises. I demonstrated that with changes to the bytecodePrimitiveClass and bytecodePrimitiveEquivalence methods, that double-dispatch equivalence and class as a message send allow surrogates to really stand in for eventual objects. Is there a way to do this without changes to the vm? For efficiency, I had also thought that with the above description of promises and their continuations, on Erights, these references could be defined precisely enough to put into the vm. If you look at my vm-redirectors changeset, you can see that I came up with a pretty clean approach to intercepting message lookup. I use the compactClassIndex to register the Messageredirector class and be able to quickly determine this in the vm. Using the same strategy, we could have special eventual send references, and promise references, that the vm could detect, then the vm could execute different lookup strategies and manage all special reference creation and resolver activation. We still need a way to implement far references and their promises so that the captp and vatp machinery can be interfaced. Are these references in the vm? Yes, but only to redirect the message send like I do in Referencecontext. See #redirectMessage: for the entry point from the vm redirector (or the MessageRedirectionProxy>>#doesNotUnderstand:). I am bothered fundamentally by having to use #immediateCallSelectors and #eventualControlSelectors to choose how to send the message. I thought that Anthony's work or Traits or MethodWrappers would be some alternatives to replacing this mess. see ( http://swiki.squeakfoundation.org/squeak-e/3 ) for SqueakElib, Scripting and the bridge code to see how #immediateRef behaves. cheers, rob

1 0

adding eventual sending to Croquet's ScriptProcess and ScriptSche duler
by Withers, Robert 14 Feb '03

14 Feb '03

Andreas, I should have sent out a quick note thanking you, 2 days ago. So..thanks for the explaination of the Script interface, and the discussion around how it works. Things got very busy at work so I didn't have an opportunity to look deeper until last night. I should have the two linked this weekend. I am currently writing an EventualScriptMessageSend, that holds and activates a resolver, when the computation is completed. This is the return continuation. I am curious about your use the ivar #myQueue in the ScriptProcess. I really like that your ScriptProcess will compute a value, and that that value is the 'result' of the process. That's a very standard view of computations. Isn't it a functional view? A better approach for supporting eventual sending may be to have a subclass of ScriptProcess which holds the continuation to the invocation site. > From: Andreas Raab [mailto:andreas.raab@gmx.de] > [TeaProcessScheduler] > > I am not sure, but I am thinking that this interruptability > > breaks the event-loop model. > > Yes, most likely so. This is a (continuous) time-driven > framework not a > (discrete) event-driven one. It still must execute activations in a sequential manner, so I wonder if it wouldn't be possible to provide 'uninterruptibility', or whatever is needed to ensure an event-loop, yet still have 'real-time' scheduling. No system-level changes, yet. :) cheers, rob

1 0

Draft Consensus Plan
by Mark S. Miller 14 Feb '03

14 Feb '03

Between the replies by Dean, Cees, Joshua, Andreas, and Rob, I see a lot of agreement and convergent thinking. Before replying to the individual posts, I thought I'd first try drafting a set of high level points, plans, and milestones that we could refine into something we're all in general agreement with. Oh, plus a bit of a twist at the end. Please fire away. * Squeak-E and Squeak are to be two similar but different languages -- both in terms of core language and standard libraries. Neither one is upwards compatible from the other, but we expect and hope that they'll be similar enough that much ordinary vanilla non-meta code may be able to be ported in either direction with little manual effort. * Squeak will be unchanged in its security status: All Squeak code in an image is assumed to be able to wield all of their user's authority. All the user's interests are fully vulnerable to -- at the mercy of -- all their Squeak code. (In the jargon, all code written in Squeak is part of the user's "Trusted Computing Base", or TCB.) * The CapTP effort ('A Functioning Interim Vat') to build a library for speaking a cryptographic capability protocol brings the power of inter-image capabilities both to Squeak and Squeak-E. It adds value to Squeak whether or not Squeak-E ever happens, and is tremendously synergistic with Squeak-E if it does happen. This is analogous to CapTP/ELib being quite usable (and used!) from Java, though CapTP is strongly integrated only with the E language. The CapTP effort is therefore an excellent early milestone with few dependencies. * Squeak and Squeak-E will run alongside each other in the one image, and be able to directly point at and call each other's objects. Squeak-E code will only be able to access a tamed subset of the methods defined on a Squeak object -- those in accord with capability discipline. (Note: I like Andreas' selector renaming approach better than my 2-method-dictionaries approach, about which more later.) * Although we don't yet know for certain what we may want to change in the existing Squeak system to better support the Squeak-E effort, we can be confident that all these changes will be upwards compatible to essentially all Squeak code, including browsers, debuggers, and various meta tools as applied to Squeak objects. * Squeak-E is to be designed for security ambition level 4: able to support unprivileged security abstractions. (As another inadequacy of my initial draft taxonomy, these levels don't say anything about self-debuggability or self-malleability.) * We wish to eventually get back to something like Smalltalk's extraordinary self-debuggability or self-malleability in a self-sufficient way, where these tools are themselves written in Squeak-E and therefore subject to capability discipline. I think this can be done eventually (as in the Safra/Shapiro virtualization layers), but it's hard, and if it's included in the first bite, that first bite will be too big to chew. (Note that E is at level 4, but without yet any self debuggability or self-malleability.) * People are understandably attached to their access to Smalltalk's extraordinary self-debuggability or self-malleability, as embodied in the browsers, debuggers, etc. My initially proposed direction of starting Spartan and then building back up to a well supported programming environment would have lost our audience. The Twist * What if, as a bootstrapping strategy, Squeak-E starts out not self-debuggable and self-malleable, but rather debuggable-by-Squeak-code and malleable-by-Squeak-code? In other words, the browsers and debuggers that we use to manipulate Squeak-E computation would be written in Squeak, not Squeak-E, would be simple adaptations of the browsers and debuggers already written in Squeak, and can therefore use the conventional non-capability-oriented meta-level power already accessible to them in Squeak. For example, by taming (eg, by Andreas' renaming) Squeak-E code would not be able to send the real #instVarAt: message to any objects. However, Squeak code can, and the existing inspectors do. Let's say further that, to Squeak code, Squeak-E objects seem to be normal Squeak objects. (Perhaps they are, but we can postpone that.) Let's say that all Squeak-E objects make their instance variables available to Squeak, but not to themselves or each other, through #instVarAt:. Then the normal Squeak-written inspectors can be used to inspect Squeak-E objects without much further work. (The further work is that doit/printit/inspectit in an inspector on a Squeak-E object should probably evaluate the selection by default as a Squeak-E expression rather than a Squeak expression.) * As Dean says, the user already own the image he's running, so if these meta-level Squeak-written tools are in fact trustworthy -- are in fact acting in accord with the user's intentions -- then it violates no actually security for these tools to be able to violate the encapsulation of the objects within the user's image. You'd be losing only the ability to run meta-level tools you don't fully trust, a basis for remote debugging in images you don't control I often run E under a Java debugger, which is logically exactly analogous, but much less pleasant. We are also making slow progress on an E-to-JVM bytecode compiler that would let us apply Java debuggers to E computation in a more pleasant fashion that would actually be analogous. I also have various debugging tools written in Java for helping to debug E code. These are effectively part of the E implementation. Likewise, from Squeak-E's point of view, all tools written in Squeak that can be applied to Squeak-E are effectively part of the Squeak-E implementation. * This direction would let the Squeak-E language shoot for level-4-with-no-meta-levels first, which is where E is currently at, before taking on something like the virtualization layers notion. And unlike E, Squeak-E could do this without sacrificing the Smalltalk-quality tool support, by just using (and slightly adapting) the existing tools. * While doing this, we should all continue discussing these fancier virtualization notions. I'd like to eventually move E in that direction as well. Do these points sound at all plausible? Does the twist sound like a good way to proceed? ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

5 4

RE: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Mark S. Miller 14 Feb '03

14 Feb '03

Rob, I admit I'm a bit confused by your message. Earlier, you wrote: At 07:49 PM 1/30/2003 Thursday, Robert Withers wrote: >Well, it has that burn the diskpacks feel to it, and that's a plus, i believe. which I applaud. In this message you write: At 12:30 PM 2/7/2003 Friday, Withers, Robert wrote: >we should only extend squeak to start supporting security, and keep it >backwards compatible. which is the opposite. In any case, for the kind of security we've been talking about, this isn't possible. (For another kind, see "A Coherent Retreat" below.) Security leverages both abilities and inabilities. Both must be carefully designed. Without the right inabilities, you don't have security at all. Once you have the right inabilities (as in my proposal that we should specify a capability secure subset of ANSI Smalltalk), then you may have security, but you don't yet have a useful system. As you add abilities back to such a system, but in a way that preserves the crucial inabilities, you make the system more usable without losing its security. I think that, by doing this, we can eventually build back up to something close to the level of functionality of current Squeak. But the result will not be compatible. You cannot add inabilities to a system the way you add a new package. New inabilities means that some old code must break. This process -- removing everything that doesn't follow capability discipline, followed by adding back in new APIs that provide similar functionality in a capability-compatible way -- is a kind of refactoring, though a much more violent case then we normally encounter. A great example is Lex's ObjectInspector in the Island's work. It moves the reflective messages from the objects themselves, where any client of the object could invoke them, and puts them instead on ObjectInspector, which can be given only to those that should indeed be authorized to break the encapsulation of these objects. (The Brand system explained earlier enables the issue of "which objects" to be dealt with in a finer-grained fashion, but that's not relevant to the points I make here.) If you think you can get to capability security in an upwards compatible way, what are you going to do about #instVarAt:? Or the APIs for opening and writing any of the user's files? Do you really want any Squeaklet to be able to do that? A Coherent Retreat There is another kind of capability security you can achieve with full upwards compatibility. It is indeed quite useful, it is the one you've already made wonderful progress on, it is where E started and stayed for years, it is the way E's largest customer is using it, and it is also the kind of security supported by Waterken Software http://www.waterken.com . If indeed the Squeak community is not willing to take the steps needed to design and build a Squeak-like capability secure *language*, then this may indeed be a good place to retreat to. In any case, it's something you need to build anyway, it's something you are building anyway, and it may be a good place to start. This alternative is to just implement a cryptographic capability protocol for communication between images. (eg, CapTP on VatTP or WOMP on VatTP or HTTPS.) (Note: even in this scenario you may wish to support multiple vats per image, but this serves no further security function. The security is as-if you were just using capabilities between images.) This kind of security is the addition of a crypto protocol library, and can indeed be added to an existing system as a package, just as you'd add any other package to the system. It contributes no inabilities to an image. All of an image is in the user's TCB, and the user's interests are therefore vulnerable to all the code he's running in his own image. What it does do is allow users to take their own authority, subdivide it into fine grained pieces or derive new authority from by abstraction, and share these derived authorities with others in order to bring about cooperation without vulnerability. One can also bring up servers acting as trusted intermediaries, as in the "mint" in the Ode. Indeed, eChat and everything in the Ode is perfectly viable at this level of security. What you give up is language-based security. Nothing above leverages the almost-capability nature of Smalltalk. You wouldn't be achieving anything that couldn't be achieved equally well by C++ programmers using a CapTP library written in C++. You'd have no ability to locally run code you don't trust, and therefore no ability to make Squeaklets happen. So if this is indeed done as a retreat, it would sadden me. I think that a Squeak-E *language* would be a wonderful thing. But better retreat than total surrender. >> "Mark S. Miller" <markm(a)caplet.com> wrote: >> > (The above argument is also bit of a preview of my upcoming >> "What's Wrong >> > with Dynamic Scoping?") >> From: Anthony Hannan [mailto:ajh18@cornell.edu] >> I agree dynamic scoping is bad (my "smart" capabilities would have >> relied on it). The only tricky thing is how to handle exceptions. At 12:30 PM 2/7/2003 Friday, Withers, Robert wrote: >Guys, I don't agree that dynamic scoping is bad, it just may not be secure >in it's current form. Colin's recent comments drives this point home. If >the environment isn't open from top to bottom to our investigation and >modification, then it isn't going to be Smalltalk. This is a critical >feature to retain. In the kind of massive refactoring we'd need to get language-based security, not only can't we be upwards compatible, we can't necessarily retain all the features we'd like. Our likes evolved without constraint of security. Some things we like may be incompatible with security. Or it may be years before we invent the reconciliation that allows us to revive some form of a feature we like without breaking security (as in my explanation of the Safra/Shapiro virtually nested virtual machines notion). In the meantime, we have to break the feature, not security. If we proceed the other way around, we'll never be secure. This means it'll go though a phase where it may be Smalltalk-like to many eyes, but where the cognoscenti may indeed judge that "it isn't going to be Smalltalk". If you're not willing to go through such a phase, don't bite off language-based security. >Traits, continuations and my eventual sending redirectors are other examples >where either dynamic scoping or system openness are crucial to allow us the >facility. Traits looks very cool, but I don't really understand them yet. Allow me to correct myself. Traits looks *very* cool! How do any of these require dynamic scoping or the existing kind of system openness (as opposed to the kind shown in Lex's Islands work)? > The reason I include both dynamic scoping and system openness, is >that the openness of Squeak _currently_ depends on dynamic scoping. In what way? ParcPlace Smalltalk 2.5 and all ancestors I'm aware of going back to Smalltalk-76 (but not Smalltalk-72), had extreme system openness without any dynamic scoping. > We >shouldn't lose this as we shift towards more security; in fact we should >only extend squeak to start supporting security, and keep it backwards >compatible. Commented on above. >We can start this process by looking at providing more vm support for >evental sending, finishing CapTP, and by migrating Lex's Islands work to >3.5. Lex's Islands work defines a new language and core libraries that is in no way upwards compatible with existing Squeak. And it cannot, given his goals, and what I've been assuming are our goals. >Thus I think the short-term (couple of months) goal should be >supporting security level 2 of Mark's original proposal. I sent out that taxonomy in order to get a sense of how far the group was willing to go and at what price. The answer seemed to be, all the way (level 4). Since then, I've been posting on the assumption that that's what we're going for. Perhaps, now that the costs are clearer, a different level of ambition is desired. Well, that's one of the purposes of having a taxonomy. But all the levels in my earlier taxonomy require language-based security. (I failed to include the above "retreat" proposal in my earlier taxonomy.) Not even level 1 (Java applet-like: does no harm, but is mostly useless) can be achieved upwards compatibly, as Java does not: Applets effectively see a different library API than do Java applications. You cannot generally run Java applications as applets. If you could, there'd be no security. > > Your right, I'm giving too much authority to Kernel creators. >> So instead >> I propose that once a creator "releases" his class he can no longer >> change it. If he wants to make revisions he has to create a new >> subclass. Others may decide to use his new subclass or not. They may >> migrate existing instances to the new class and/or use the >> new class for >> new instances. > >I don't like this restriction. Classes and code should be able to evolve. >Now if an 'Island' has classes bound into it, those classes shouldn't >change, unless the right capabilities to change them are held. And what are the right capabilities? >I think the argument Mark is making is that there isn't a central authority. >In fact, there is no third party security sever or third party interface >respository. I do think that we could specify the protocols for a base >library, but that's really what the ANSI spec is about. There may be some >library specification additions for supporting security/eventual sends. Well, I am making that point. But in the context of Anthony's design -- a distributed shared heap, in which all replicas of an object are considered to be the "same" object -- then, for replicas for which there's no one party that everyone else is willing to take as authoritative, such objects must be immutable. If you don't like the immutability, then some other assumption must give, which is plausible, but leads to a different design. >> MarkM wrote: > >> > Same problem then. I think these can't be automatically >> replicated, because >> > there is no one authority everyone would mutually trust. At >> least I hope there >> > won't be. A world in which there's some one authority >> everyone is willing to >> > make themselves fully vulnerable to is a world ripe for >> dictatorship. >> >> Yes, like above I will change this so no one has authority once the >> pool is "released". However, I will still allow the creator >> to add new >> classes to a pool. This is where he could add his new >> subclass versions. >> Adding to a pool is benign. > >Again, I think that with the right capability, these things could be changed >'locally'. The issue is that there isn't a global authority. You're "locally" implies a change of assumptions that probably could be made to work, but breaks the uniformity of the distributed heap notion Anthony is trying for. It would lead to a different design. >I am encouraged that although this list is turning out to be on the quiet >side, there is much interest in what we are considering. The fact that we >are doing so in a thoughtful way is to our advantage. I've been curious about the sudden quietness myself. >I will be a little more active this weekend, now that the work week is >winding down. I want to implement RemoteHandlers (virtual circuits with >remote objects) and the objectMap. > >The other dimension, that I have been doing a little work with this past >week, is cleaning up the EventualReferences. I am hanging out on the IRC >channel #squeak-e and will be available there to guide anyone wanting to >dive into this very intriguing mechanism. Look at ReferenceContext (the >eventual reference), and RedirectionManager (the underlying redirection >mechanism). If you build a redirection vm, make sure you doit to >'RedirectionManager enable'. I will update the SqueakElib package this >evening. Cool, looking forward to it! ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

7 8

Re: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
by Robert Withers 12 Feb '03

12 Feb '03

Andreas, I'll just cc the list in response, since this may be interesting and related to our writing a squeake processor. All'y'all, I looked into Croquet and there are in fact two schedulers. Of course, Andreas, is the man with the answers. In a SqueakE vat, I can imagine that there could be multiple stacks pending for some event to occur. Is being uninterruptible the important property of an event-loop? On Wednesday, February 12, 2003, at 06:22 AM, Andreas Raab wrote: >> The real-time scheduling of future messages is the concurrency >> mechanism of choice, I would think. Your scripts make it an >> event-loop, although I suspect that the TeaProcessScheduler >> is also an event-loop. The crucial thing about an event loop >> is... what? Could it be that they are uninterruptible? > > True for the script scheduler (within scripts), not true for the Tea > scheduler. scripts do not interrupt each other, they have "stepping > semantics". The tea scheduler has earliest deadline first policy which > means > it _can_ interrupt another process if work with an earlier deadline is > being > scheduled. I am not sure, but I am thinking that this interruptability breaks the event-loop model. > >> TeaProcessScheduler has several structures of processes. There is a >> heap for timeouts (pending), a heap ordered for deadline (to occur), >> and for lookup, but only by TeaTime, not symbols. How does it deal >> with symbols and pattern-matching? .. oh, the times are inserted by >> the MessageSend, so it does have pattern-matching through sending. >> How does it support an event system? Well, the appropriate >> MessageSend >> could occur. > > Like I was saying, much of this is still in flux. We are not quite > certain > yet, how the earliest deadline first scheduling interacts with the > scripts. > Part of this is the model of time which David develops. IOW, each > process > runs "in time", and accesses state "as of" a particular time. If that > time > hasn't come yet it will block (or alternatively perform an eventual > computation which may later be aborted due to changes at "some earlier > point > in time"). Much of this hasn't been implemented yet. The scheduler (as > of > now) only garuantuees strict earliest deadline first scheduling. > >> ScriptProcessor, creates chained handlers and then suspends >> the process (but not always). The handlers are looked up by >> pattern matching whenever events occur. So you added yet another >> event system! ;-) > > For the scripts, the policy is really simple: Scripts either run to > completion or until they wait for something to happen (this might be an > event or a time out or a semaphore signal). Which is exactly what step > methods do (in a generalized sense). What you see in some places (the > "but > not always" part of the above) is mostly implementation detail which > ensures > that certain critical notions are preserved. Such as (for example) > that when > we enter a critical section *and* the process entering it can aquire > the > lock immediately that it will not be suspended. This turned out to be > critical for a number of places. > >> I like the semantics of it. #signal sounds like it is a more >> fundamental mechanism than dependencies or the multicast events; >> like exceptions, but without all of the stack manipulation. >> that would mean that it is an exception capability secure design. >> :) In fact it uses a pattern-matching mechanism, much Linda-like, >> to reschedule scripts for execution. So how does it deal with time >> and time events? Ahh, a tick list. > > No, this is only a little optimization to get some stuff more easily > out of > it. Conceptually, this tick list doesn't matter - it's simply a > convenient > way of allowing scripts to happen on each "world tick" (simulation > cycle, > vat turn, you name it). What are the entry points you use for suspending a script until an event occurs (#waitUntil:), creating and running a new script (#runScript:), triggering an event (#signalEvent:)? I tried following the senders until it got to something that looked like public protocol, but I keep running out of senders. :) Certainly the pattern of creating a new ProcessScheduler and defining the Processes that use it as non-preemptable and uninterruptable, *at least among each other*, may allow this minimal Squeake engine to be built. My DispatchSecretary is slow and needs replacing. Could we just use the ScriptProcessor for our squeake event-loop or should we roll our own? cheers! rob

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Squeak-e