On Wed, 2003-09-24 at 15:44, Rodrigo Moya wrote: > On Wed, 2003-09-24 at 23:32, Bob Smith wrote: > > Another question for the design doc. > > > > The current design seems to be based around a plugin offering up > > services to be consumed. The application is then in charge of consuming > > a service. The question is, how do we handle the user going into a GUI > > and telling the app to unload the foo plugin? It can't be unloaded > > until the application stops using it. Should we have an event of sorts > > on a plugin class / service class to say, this plugin is unloading, > > expect it to go away? That sounds like it could be a lot of work for > > the programmer using the plugin system. > > > we already have the ref counting thing in GObject, so I think the best > thing is that plugins unload themselves when the ref count reaches 0. > > > We could use refcounting and say, the plugin is unloadable only when > > refcount is 0. But then the app can't hold on to a service when its not > > being used. For my app, this wouldn't work well at all. It could work > > for my app if I forced the use of ghost services so maybe it is ok. > > > if an app wants to unload it, and it still has some references, it will > just refuse to be unloaded. > If you have a look at my previous post, I give an example of where the plugin could fairly easily be safely unloaded if its notified that it wants to be unloaded but needs to hold a reference for performance reasons. I'm thinking an event/refcount mechanism would be good enough. If refcount is 0, unload. If not, issue an event which either would bring the refcount to 0 which then you can unload, or it never does, and you just leave it loaded. How does that sound? > cheers cheers -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part