Ref.whenResolved

Thomas Leonard <[email protected]>
Newsgroups gmane.comp.lang.e.general
Message-ID <[email protected]>
Ref.whenResolved makes this guarantee:

     * Should the reactor be invoked with a
     * non-broken value (and therefore a fulfilled value), all earlier messages
     * sent on ref before the whenResolved are guaranteed to have been
     * successfully delivered.

This seems excessive. For example, if you do this (to ensure that
farRef is resolved):

  when (farRef) -> { ... }

it forces a network round-trip before the when block executes.

And if you do:

  when (def results := rcvr<-getData()) -> { ... }

it transmits the result data over the network twice!


While trying to simplify the causality traces, I added a
Ref.whenResolved(reactor) instance method. This does E.send(reactor,
"run", resolution) as soon as the resolution is known. e.g. a NearRef
does:

    public Throwable whenResolved(Object reactor) {
        return E.sendAllOnly(reactor, "run", new Object[] {myTarget});
    }

SwitchableRef and OldRemotePromise queue up reactors locally and call
resolutionRef.whenResolved() once committed.

In my previous example (invoking a simple increment() method in a
remote vat), this reduces the number of turns from 11 to 6, makes the
causality graph a simple chain (no fork), and only sends the result
value over the network only once.

Before, a deliverOp used four turns:

1. Receive CapTP deliverOp message:
    Ref answer := E.send(target, verb, args)
    E.send(answer, "__whenMoreResolved", rdr) # (tell the remote
caller the result)
2. The actual method is invoked. answer resolves, enqueuing the
__whenMoreResolved on the vat (now = false)
3. PendingDelivery does E.sendAll(result, "__whenMoreResolved") (now = true)
4. __whenMoreResolved does E.send(rdr, "run", self)

Now, it uses two:

1. Receive CapTP deliverOp message:
    Ref answer := E.send(target, verb, args)
    answer.whenResolved(rdr) # (tell the remote caller the result)
2.  The actual method is invoked. answer resolves, enqueuing the return message

I'm wondering whether it makes sense to do this always, not just when debugging?

What was the rationale for requiring previous messages to be delivered
before running the when block?
What is the "now" flag for for messages enqueued on a vat, and why
does Vat.qSendMsg set it to false?

Thanks,


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.