gmane.comp.lib.vos.devel

Lalo Martins | 16 Feb 06:26

gc

Also spracht Lalo Martins (Fri, 15 Feb 2008 06:20:22 +0000):
> (Now, on my original design, web pages would be "transient views",
> meaning, there is a ViewImplementation that writes to the WebRequest,
> but it never actually returns a View.  This feature has been lost on
> Peter's implementation, but we plan to bring it back later on; just not
> a very high priority.  For now, by not attaching the View to any site,
> the ViewImplementation can make sure it's collected in the next gc
> cycle.)

Er, except we have no gc at the moment :-D so even things like the 
WebRequest object will just linger forever in the Site's vobjectTable 
until the process is restarted.

I went ahead and re-added transient views, essentially by moving the 
createView() logic from the ViewFactory to the ViewImplementation, where 
it can be overridden.  But that means I'll still be leaking WebRequest 
objects.  Is it as simple as adding a Site.releaseVobject(vw) method (to 
delete vw from the vobjectTable, therefore allowing the refcount to 
eventually reach 0)?  Or am I missing some implications?  I know later on 
we want to have a smarter, proper gc, but for the simple case...

best,
                                               Lalo Martins
--

-- 
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
                           -----
                  http://lalomartins.info/
GNU: never give up freedom              http://www.gnu.org/

(Continue reading)

headers

Lalo Martins | 16 Feb 07:49

Re: gc

hate to answer myself, but 

The recipe for "transient" objects is:
factory.create(core::SiteWrapper(), fooComponent::implementation())

It will have no site, and its vobjectId will be 0.  And it won't be in 
any site's vobjectTable, so when the refcount reaches 0, it's gone.

best,
                                               Lalo Martins
--

-- 
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
                           -----
                  http://lalomartins.info/
GNU: never give up freedom              http://www.gnu.org/

headers

Peter Amstutz | 19 Feb 03:39

Re: gc

On Sat, Feb 16, 2008 at 05:27:38AM +0000, Lalo Martins wrote:
> Also spracht Lalo Martins (Fri, 15 Feb 2008 06:20:22 +0000):
> > (Now, on my original design, web pages would be "transient views",
> > meaning, there is a ViewImplementation that writes to the WebRequest,
> > but it never actually returns a View.  This feature has been lost on
> > Peter's implementation, but we plan to bring it back later on; just not
> > a very high priority.  For now, by not attaching the View to any site,
> > the ViewImplementation can make sure it's collected in the next gc
> > cycle.)
> 
> Er, except we have no gc at the moment :-D so even things like the 
> WebRequest object will just linger forever in the Site's vobjectTable 
> until the process is restarted.

What do you mean by "garbage collection" in this context? Although I've 
toyed with the idea of using the Boehm collector, the current automatic 
memory management system (which I assume is what you're referring to) is 
just based on reference counts.

> I went ahead and re-added transient views, essentially by moving the 
> createView() logic from the ViewFactory to the ViewImplementation, where 
> it can be overridden.  But that means I'll still be leaking WebRequest 
> objects.  Is it as simple as adding a Site.releaseVobject(vw) method (to 
> delete vw from the vobjectTable, therefore allowing the refcount to 
> eventually reach 0)?  Or am I missing some implications?  I know later on 
> we want to have a smarter, proper gc, but for the simple case...

I think what I was planning on doing to address this is to have the 
vobject table on the site not increase the reference count.  So, you 
could have a "transient" vobject which is still listed on the site, and

(Continue reading)