Re: [Fresco-devel] kit destruction not informing the server?

Over IRC, Tobias and I hashed out a couple of ideas. The "obvious" 
quick-fix, to increment the Kit an extra time on construction introduces 
a bad bug: the exit button doesn't work in the demo.

Tobias suggested that the Kit might use a static function to inform the 
server context about its destruction, but it's unclear to me whether the 
server context is a singleton (like server is) and whether it's possible 
to make the contexts' cache of kits (the _kits variable) static.

I'm hoping that Stefan might know what's going on here.

Nick

Tobias Hunger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Saturday 14 September 2002 04:16, Nathaniel Smith wrote:
> 
>>>I've heard that this lifecycle stuff can be complicated so I'm asking
>>>what the correct fix is. I see two options:
>>>
>>>a) make the ServerContextImpl test that the kit is still valid before
>>>trying to make calls on it. (Not certain myself how to do that.)
>>>
>>>b) make the KitImpl hold on to a ServerContext_var and add a function to
>>>the API that allows the Kit to inform the server context that the kit is
>>>now gone
> 
> I think the basic mechanism is fine. It is just that the object (the 
> ServerImpl iirc) does not mark the fact by increasing the refcount. So once a 
> application releases its reference the refcount goes down to 0 and the object 
> is destructed.
> 
> The proper fix is IMHO to store a
> struct plugininfo 
> 	string name;
> 	string filename;
> 	Plugin<KitImpl> *plugin;
> };
> instead of the raw Plugin<KitImpl> in ServerImpl.cc. Then when we scan() for 
> plugins, fill in the struct, unload the plugin again, set plugininfo::plugin 
> to 0. Once a client requests a Kit we check for plugininfo::plugin == 0 and 
> if so load the plugin and else return a reference of the kit we allready got 
> loaded.
> 
> It is wrong to load every Kit on the server's startup anyway. By the way: This 
> is basically how Babylon handles its modules too.