Deactivated Plugins and Interfaces

[James Liggett]

Hi,
While looking into bug 591559, I came upon a question about how plugin
deactivation and interfaces work. The problem that this bug exposes is
that the file manager tries to query the git plugin for file status even
after it has been deactivated, creating a condition where some
structures are being used after they've been destroyed. Are deactivated
plugins still expected to perform their interface implementation duties
after they've been deactivated?

Thanks,
James


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi James,

James Liggett a écrit :
> While looking into bug 591559, I came upon a question about how plugin
> deactivation and interfaces work. The problem that this bug exposes is
> that the file manager tries to query the git plugin for file status even
> after it has been deactivated, creating a condition where some
> structures are being used after they've been destroyed. Are deactivated
> plugins still expected to perform their interface implementation duties
> after they've been deactivated?

I'm not sure but I think currently a deactivated plugin still has to
avoid a crash, like a disposed but not finalized GObject. We could
perhaps update to documentation to make this more clear.

Something sure is that deactivated plugins are not unloaded, so the
plugin object is not destroyed. I have opened a possibility to do it but
it will cause problem if the plugin (or a library used by the plugin)
registers static GObject type which is done commonly. There is a problem
too if the plugin is freed because it will obviously not be able to
avoid a crash. A plugin using an interface needs to use a weak pointer
or something like this, to get a notification when the interface is
destroyed.


Then a possible improvement could be to have a function like
anjute_shell_get_interface_watch or something like this that emit a
signal or a callback when an interface becomes available or unavailable.
Such function could be used by a plugin needing an optional interface,
by example the file manager can use the version control interface.

So a plugin using this function can easily avoid calling a deactivated
plugin. Moreover, if the user deactivates one plugin and activates
another one, the plugin follows correctly the change. By example, the
file manager is started with the git plugin, then this git plugin is
deactivated and a cvs plugin is loaed, the file manager will now show
the CVS state of each file.

This can be used for the symbol-db plugin too, I think it can be
optional even if it's not the case currently.


Having the function above still not guarantee that a deactivated plugin
will be never call. In order to do this, we need that the function
anjuta_shell_get_interface increments a reference count to avoid
deactivating the plugin while someone use it. But then it needs a
function to decrement this reference count. And finally, it needs that
we don't have a loop in plugin dependency, I think it's possible
currently but I don't know if it's useful. Else we need a 2 steps
destruction like GObject which is perhaps overkilled in our case.


To make a summary, after writing this mail, I think it's almost needed
that deactivated plugin avoid crash. Then, I think we could improve the
way the plugin are currently working, I would like to have more optional
plugins.

Regards,

Sébastien

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

Hi!

A way to avoid that could be to hold a weak reference on the git plugin
in the file-manager. So once the git plugin gets deactivated, it will
stop querying it.

But the git plugin has to be sure to answer all queries in the queue
before it deactivates itself.

Regards,
Johannes

Am Mittwoch, den 12.08.2009, 17:28 -0700 schrieb James Liggett:

> Hi,
> While looking into bug 591559, I came upon a question about how plugin
> deactivation and interfaces work. The problem that this bug exposes is
> that the file manager tries to query the git plugin for file status even
> after it has been deactivated, creating a condition where some
> structures are being used after they've been destroyed. Are deactivated
> plugins still expected to perform their interface implementation duties
> after they've been deactivated?
>
> Thanks,
> James
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Anjuta-devel mailing list
> Anjuta-devel@...
> https://lists.sourceforge.net/lists/listinfo/anjuta-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi Johannes,

Johannes Schmid a écrit :
> A way to avoid that could be to hold a weak reference on the git plugin
> in the file-manager. So once the git plugin gets deactivated, it will
> stop querying it.

I think a weak reference doesn't work because the git plugin is not
destroyed only deactivated.

I think there is a "plugin-deactivated" signal, so we could get this
information. But as every plugin using an interface needs to use it, I
think it would be useful to have an easy function replacing
anjute_shell_get_interface that is doing this.b Probably connect to both
"plugin-activated" and "plugin-deactivated".

Regards,

Sébastien

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

Hi!

> I think a weak reference doesn't work because the git plugin is not
> destroyed only deactivated.

You might be right here.

> I think there is a "plugin-deactivated" signal, so we could get this
> information. But as every plugin using an interface needs to use it, I
> think it would be useful to have an easy function replacing
> anjute_shell_get_interface that is doing this.b Probably connect to both
> "plugin-activated" and "plugin-deactivated".

I think the problem is that for example in the file-manager, the
interface is cached so a helper function would not help. The
file-manager plugin in addition does some more plugin querying work to
get the correct version control plugin. Doing so for every interface
call would be a massive waste of resources.

IMHO, only very few plugins that are use (de)activatable expose
interfaces and for those the caller could be responsible if the plugin
still exists.

Regards,
Johannes


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi Johannes,

Johannes Schmid a écrit :
> I think the problem is that for example in the file-manager, the
> interface is cached so a helper function would not help. The
> file-manager plugin in addition does some more plugin querying work to
> get the correct version control plugin. Doing so for every interface
> call would be a massive waste of resources.

I think that if you get a callback only when a plugin implementing
IAnjutaVcs is activated or deactivated, it will not happen very often so
it looks fine for me.


> IMHO, only very few plugins that are use (de)activatable expose
> interfaces and for those the caller could be responsible if the plugin
> still exists.

It's true that it's not very common, but it should be more common when
Anjuta code will be more mature. The goal of having an IDE is that all
parts could communicate easily with more powerful methods than pipes. I
would prefer that more plugins can be deactivable by the user like git
plugin. I think it's useful to make this as easy as possible.

I think a similar bugs could happens with the project manager, the debug
manager and probably other plugins. It is just more difficult because
most of the time, the interface is used on an user request and the
plugin is deactivated when the project is closed, so both should happen
at the same time.

I think it's important for the caller to know if an interface is
activated or deactivated. This can be used to disconnect from a
deactivated interface but to automatically connect to a new interface too.

Then, I'm not sure if it's enough to avoid calling a deactivated
interface. By example if you have a plugin A depends on B which depends
itself on A. If you deactivate A first, when you deactivate B you cannot
call A because it's already deactivated. And you get the same problem if
you start with B. That's why, I thinking that deactivated plugin should
still avoid crash like in its "disposed" state. I'm not sure that this
case really happens though so perhaps it's not necessary.


Finally, I have another issue with plugin activation. Currently, the
file manager requests a plugin implementing IAnjutaVcs if it exists. So
when you load a project using git and the Git plugin is not loaded, you
will get it automatically. So even if you disable this plugin in the
preference (it is user activable), close the project and open it again,
you still get the Git plugin. In fact, if your project uses git, there
is no way to disable this plugin, it is not really user activable.

This behavior is perfect for a new user who doesn't know which plugin
exist, but it's annoying for more advanced user who can decide to remove
a plugin because it crashes, takes too much resources, or it doesn't
like the logo....

I don't know how to do this. Perhaps by having a list of disabled
plugins. So all plugins requested by another one (= implementing an
interface, like git plugin) should be not user activable. They will be
loaded automatically when needed, but could be disabled.

Regards,

Sébastien

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel