Re: possible garbage collector problem...

[Hugh Hoover <heh>]

...
TYPE foo=g(x);
f(foo);


garbage collection between statements.

I think that this would only be a problem with relatively uncontrolled task
switching, or if f(x) caused a gc to occur before ensuring the object will
stay around.
  For the first case, my interpretation of KeyTalk++ (our tasking model), is
that it is not pre-emptive - and therefore shouldn't be a problem (right MarkM?)
If g(x) caused a gc, there is no problem because it must ensure that it is
hanging onto its result before returning.  If there is no preemption, nobody
else in the server should be able to run and cause a gc.
  The harder problem is if f(x) allocates (or does something else to cause
a gc).  It is possible for f(x) to be written assuming that somebody else will
be ensuring that x sticks around.  This is something we should pay attention to,
and write defensively - which, of course, increases overhead or requires
careful attention to static calling patterns to ensure there's a StrongPointer
somewhere on any object that has to persist over a gc.
  There's a similar problem on the Mac, where an object may be moved in memory
during allocation.  The Pascal compiler helps by flagging statements that
pass addresses rather than handles.  This occurs when a field of an object
is passed rather than the object itself.  (This occurs frequently when calling
Mac Toolbox stuff)  The upshot is that there is a lot of defensive programming
to ensure parameters will stay put.

--Hugh