Re: [Fresco-devel] Graphic_var's and server stability

Neil Pilgrim wrote:
> After chatting to Stefan I've just been pondering on why a Graphic_var
> is needed in a line such as:
> 
> vbox->append_graphic(Graphic_var(layoutkit->vfill());
> 
> My understanding is as follows:
> - both the vbox and the vfill are graphics (corba objects) whose
> servants reside in the server
> - when the vfill() call returns, it gives a Graphic_ptr, which should be
> released in the client address-space

just to avoid confusion: let's restrict the entire discussion to Graphic
*references* ('proxies'), not servants.

A method that is defined such as 'Graphic foobar()' will result into
a C++ method 'Graphic_ptr foobar()', i.e. it returns a Graphic_ptr,
or, spelled differently: 'a reference to a proxy to a Graphic object'.
Since 'foobar' doesn't know where the object is handed back to, i.e.
whether it remains local to the application or whether it is marshalled
over the wire, it has to turn over the reponsability to free the returned
object (reference). Proxies are shared, so you acquire a reference by
'_duplicate'ing it, and you free it via CORBA::release().

That's why you'll see implementations such as

Graphic_ptr foobar() { return Graphic::_duplicate(my_baz);}

and

Graphic_ptr baz = foobar();
...
CORBA::release(baz);

However, calling release explicitely is annoying, and error-prone
(especially in the light of exceptions, which are quite frequent in
a distributed environment).
Now comes the hour of the smart pointers: 'Graphic_var' will, when
a Graphic_ptr is assigned to it, simply take it over, and call
release on it in the destructor. That's pretty similar to std::auto_ptr.
With this, the callee code looks just:

{
   Graphic_var baz = foobar();
   ...
}

Now the other half of the equation: in a call to a method

'void boom(in Graphic g)' (in C++: 'void boom(Graphic_ptr)')
the argument is *not* consumed by the callee. If you want to
keep it in the callee, call _duplicate there...

So, would you call 'boom(foobar())' directly, you'd leak, as
foobar() increments the ref counter, but nobody releases it.
The solution is thus:

boom(Graphic_var(foobar()));

> - Graphic's are dynamically allocated, and deallocated when no
> references point to them; this is both server-side and client-side
> references

nope. We are talking about references only, and their ref counting
is not distributed, i.e. it is bound to *one* address space.

> - if we don't use a Graphic_var above, then although the Graphic_ptr is
> passed to the append_graphic() function, the Grapic_ptr is not released
> locally (and no variable-name is available to do so)

see my above explanation

> - no Graphic_var therefore leads to an extra reference to the vfill
> sitting on the client-side, which cannot be released

yes

> - an unreleasable reference leads to the Graphic in the server (ie.
> vfill) not being unallocated when it is no longer required, since there
> will always be one client-side reference.

that's not true in general. It is true if you use distributed ref counting
(as we do), where the lifetime of proxies is coupled to the lifetime of
servants (using the right smart pointers, of course).

> Is this a correct analysis? If so I think it would be useful, in
> addition to a coding style-guide, to have a 'corba style guide' or
> similar, maybe in a FAQ style, with gotchas like the above. Perhaps I've
> just not read H&V cover-to-cover enough, but although a problem like
> this is hinted-at, its not made explicit? 

I totally agree, this whole issue can't be stressed enough. I'v started
to cover it in the tutorial at http://www2.fresco.org/tutorial/index.html
(Appendix B), and everybody is welcome to comment on that (and even enhance
it !)

> If I got the above correct, what I'm also concerned with is the way that
> a client could easily be (badly) written such that it leaks
> graphic-references. When this client exits, will all the graphics that
> it requested be deleted? I believe that would be desirable; even if we
> want to keep some graphics from the client, they could be copied before
> the client quit, but I'm not sure if this would remove the benefits of
> deleting the original graphics.

yes, all resources allocated by the client will be released when the client
disconnects, no matter how. That's indeed crucial.

Regards,
		Stefan