Re: Plugin Unloading

> There are 3 layers of restriction that I can think of
> 1) The plugin loader can not unload things (eg your example of
>    systems that do not support unloading)
> 2) The plugin itself is using resources that it can not shut down
>    easily.
> 3) A service in the plugin is inuse or unable to shut down.
> It seems relatively easy to handle all three.

Agreed. The one question I have is, how much of this can be determined
ahead of time so, say, the GUI for loading/unloading can gray out loaded
unloadable plugins.

As for number 2, I always thought that the plugin object was
uninheritable. Are we going to be able to subclass the plugin class?

> > This is interesting. As I understand it, you would have to use a proxy
> > object correct? Are you talking about reloading a plugin where the
> > application doesn't know the plugin was ever removed?
> There are two choices, proxies, or a registry of service users.
> This would be handled at the application level.

How I was thinking of it is if:
1. All services of a plugin that are used in an app were gotten as
proxy's from the plugin manager
2. All services of the plugin notify the the plugin manager that they do
not function as a generator, say, returning an object defined in the

Then you can have the plugin manager keep track of pointers to all proxy
services returned, and update their internal service pointer when the
plugin is reloaded. (Or, null out the pointer so that the proxy will
retry to get the service next access)

But, there is one problem left to be resolved. What happens when a
plugin is reloaded, and the old plugin worked, but the new plugin fails
to load? Well, come to think of it, a proxy service will have this same
problem if the plugin fails to load. How should we handle proxy services
that fail to load plugins?

Bob Smith <bob thestuff net>

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]