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