On Wed, 2003-09-24 at 16:43, Dave Malcolm wrote: > On Wed, 2003-09-24 at 21: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. > > That'd be a nightmare. I'm expecting more of a reference-counting > system. I'd expect the service class to ref/unref the plugin as service > objects are instantiated/destroyed. You could also have an instance > count in the service class, so that each service can track how many > objects are around. I'm thinking maybe a cross between the two. Refcounting with a signal. If the refcount is 0, unload. Otherwise, emit an unload signal on the plugin. Anything holding a reference to a plugin that can be safely removed can wait for an unload signal, do whatever it needs to remove the plugin from that part of the app, and then unref. When the refcount hits 0, then the plugin's unloaded. > > Getting more complicated, can you have dependencies between plugins or > services e.g a plugin which uses functionality from another plugin? > Yes. With the idea above, the unload event could be emited on all dependent plugins first, and go down the dependency tree until it gets to the plugin your trying to unload. > > > > 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. > > > Can't you just hold a dummy reference to stop the thing being unloaded? > When the user requests an unload, you release that reference. Then the > plugin gets actually unloaded when all the service objects go away. > Ok. Here's an example from my application. I can extend my app to take in multiple scripting languages. These are exposed to the user via a multiplexer. Text goes to the scripting language that is currently selected or one that is specified explicitly. The plugin system would need to support getting one instance of each scripting language service for me and I would regester each one with a name in hash table. So, something like: "R" -> R object "python" -> python object At any time, the system might get a request to send data to a plugin. I don't want to get a new instance of the plugin, send a line of text, then refcount back to 0 each time. That would be a huge performance hit. What would be better is, if I could hold on to the object, and be told when its to be unloaded so I can remove it from the hash myself and do the final unref. Am I the only one that would need this kind of thing or can other people think of a use? > > > Thoughts/Comments? > > > > --- Bob Smith <bob thestuff net> --- > > ++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++ > > ..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part