Asynchronous visual applications and the unum pattern

You know, despite having read the blog post on it several times, I think I’m only just starting to grok the unum pattern now that I’m noodling on a particular problem that I think might require it. “You can’t tell people anything” and all that. :wink:

The specific design constraint that led me to this is: I want to be able to render a graphical application which has multiple objects (whose logic may live in multiple vats or even on multiple machines!), with each object able to display a representation of itself on the screen. It doesn’t matter that much in my case if a single object hitches or stops rendering for a moment, but it does matter if a single object is able to cause the whole screen to do so.

This doesn’t ordinarily seem to play nicely with asynchronous objects, because it feels like rendering really wants to be a synchronous operation - things can’t take very long because you’ve only got a small time budget for each frame. If you’re sending an asynchronous message to each object asking it for its visual representation, that could potentially take a while, during which you’re unable to render the screen. (Plus, in the case of Goblins objects, you can’t really get return values from an asynchronous message.)

But if instead of each one being a single object it’s a distributed object (a unum), this might be easier. You could have one “rendering presence” for each unum in a central vat that’s responsible for returning the current visual state of the object (synchronously!) during a render loop. And then in addition to that, you have (let’s say) a separate “logic presence” for each unum (which is the original object I was thinking of). The logic presence is then responsible for updating the state of the rendering presence asynchronously, which thanks to Goblins it can do transactionally (and thus this will never happen while the rendering presence is being called by the render loop).

I haven’t yet actually tried implementing this, so I’m sure there are some pitfalls I’m not seeing yet, but I woke up this morning realizing this might solve my problem and had to get it out of my head! :slight_smile:

1 Like

I’m looking forward to releasing the EC unum source in the coming weeks. There are several original unum for EC Habitats implemented there. You will be able to see how we separated rendering & UI from from state-logic. In the original model, a presence represented the unum/world-object in each local vat that was interacting with the unum.

1 Like