[Fresco-devel] Graphic_var's and server stability

Neil Pilgrim <[email protected]>
Newsgroups gmane.comp.video.fresco.devel
Message-ID <[email protected]>
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
- Graphic's are dynamically allocated, and deallocated when no
references point to them; this is both server-side and client-side
references
- 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)
- no Graphic_var therefore leads to an extra reference to the vfill
sitting on the client-side, which cannot be released
- 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.

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? 

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.

Comments?

-- 
Neil
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.