Posted by
Andreas.Raab on
Jul 23, 2006; 4:07am
URL: https://forum.world.st/camera-in-CroquetEvent-tp129366p129368.html
Howard Stearns wrote:
> What's the definition of "island discipline?" I think it has something
> to do with no island (including the Island default) holding on to any
> long-lived references to something in another island.
Really only that an object mustn't refer directly to objects in other
islands.
> - But there are exceptions that are allowed, such as classes.
Unfortunately, yes. Couldn't make it work for the time being without
those :-(((
> - And I'm not sure what the limitations are on transiently held
> references. Empirically, I know that the execution of a future message
> from the Island default to another island can pass something on to the
> Island default (e.g., a CroquetEvent), but I imagine that the island
> better not store that reference such that it's still around when the
> island tries to sync.
With proper future messaging this isn't a problem. A CroquetEvent for
example gets copied when it's passed into the island. So storing isn't a
problem at all. Generally, all objects get copied when you pass them
into an island unless you pass a reference to an object inside that
island. The only exceptions are classes (as you noted above).
> I don't know how to look at it right. Here's my thinking, but it would
> lead me to believe that snapshots would reliably fail all the time,
> which they don't:
> The snapshot trace (below) shows that when the event holds the
> camera, then the Island default (outside) has a reference to the camera.
> OK, that's fair. And it shows that the island being sync'ed has created
> a TFarRef to the camera. Thus the island (inside) and the outside both
> reference the camera. Bad. I think the reason the island makes a
> TFarRef to the camera is that event handlers like #pointerDown: pass the
> CroquetEvent, which is passByClone:, and so it tries to pass the camera
> in turn. Since the camera is passByProxy:, it creates a TFarRef.
Yes, but this wouldn't apply in the case of a future message. Your
analysis makes sense in the situation that the event is used in a
synchronous send; but I'm not sure where this would happen. Here is
something to try: Change TCamera class>>howToPassAsArgument to something
that will raise an error when you try to execute it (say #passByFoo:) to
see where exactly that reference is created.
Cheers,
- Andreas