Re: Planning for for 4.4 panel

Richard Stellingwerff wrote:
>>Hi all,
>>2) Out-of-process plugins. This should protect the panel from problems
>>   in plugins (mem-leaks and crashes).
> 
> I'm not sure if I understand what 'out-of-process' means. Does this
> mean each plugin will be it's own application, just like with
> gnome-panel? Because that's one of the things I *really* hate about
> the gnome-panel. Run a bunch of 'plugins' and your memory usage rises
> to incredible heights.
> 
> I hope I'm wrong, but if not then I strongly discourage you to do this.
> 
> Please don't bloat XFCE... :(

I think this topic is easily misinterpreted. I'll try to bring some 
light into this and explain why it is a good thing to have 
out-of-process plugins:

First of all, there'll be in-process plugins like we have currently. The 
out-of-process plugins are just another possibility, they're not meant 
to replace the in-process possibility.

For trivial plugins its best to run in-process, simply because the 
plugin has no requirements other than the xfce4-panel ones. E.g. the 
clock plugin is such a plugin. It is simple and all libraries required 
for the clock plugin are already loaded into the panel process anyways.

For non-trivial plugins, there are some things to take care of when 
loading into the panel process. The most important point is the 
dependency on other GObject-based libraries.

For example, for Xfce 4.4, a trash plugin should be available that 
offers fast access to the trash (dnd, open, etc.). This plugin will use 
the Thunar-VFS library, which provides an implementation of the Trash 
spec. The Thunar-VFS library in turn depends on libexo and probably 
other libraries (D-VFS in the future), which means all these libraries 
would need to be loaded into the panel process. Now there's no problem 
up to this point. But if you take a closer look at the libraries, you'll 
see that atleast libthunar-vfs and libexo use static GObject-typing 
(mostly for performance reasons).

Now why is that a bad thing for the panel? Well, quite easy to 
understand: Static types are registered exactly once with the GType 
system and the GType system makes sure that these types are never 
finalized. The type id of these types is stored in a static variable in 
the library's data pages. Now if one of these libraries would be 
unloaded from the panel process, the types registered by this library 
would not be unregistered. And next time the library is loaded and a 
call to the appropriate _get_type() function is made, it would try to 
register the same static type again, which would fail - of course - and 
the panel will crash.

Ok, you could say, let's change libexo and libthunar-vfs to use dynamic 
types instead of static types. We could even do this - tho it's really 
not a good idea, atleast not for libthunar-vfs, where ThunarVfsURI is a 
fundamental type, which can't be dynamic, and libexo has some boxed 
types, which would also be tricky to work-around - but then you'll 
probably want to write a plugin that uses libabc, which also uses static 
types. And so on. All currently existing GObject-based libraries use 
static types, simply because that's the way it's meant to work.

So, you'd make the plugins in question persistent, which in turn makes 
the dependent libraries persistent, which in turn means that the memory 
for the mappings and the memory allocated for the types (most probably 
on the head) will never be freed. Not really a problem, as the kernel 
will probably swap these pages after some time. But it's (a) more of a 
"bloated solution" and (b) a really ugly hack, which could be avoided by 
using out-of-process plugins.

The above discussion doesn't even take into account the case where 
libraries allocate a lot of heap memory, that is never freed unless the 
process terminates (yes, there are a *lot* of libraries out there that 
do this).

And the above use-case only concentrates on the libraries issues. There 
are a lot of other issues when doing non-trivial things within the 
process of the panel, which does not only complicate things, but also 
makes the panel unstable (for example, a plugin that leaks memory or a 
plugin that doesn't properly unregister main loop sources, etc.). We've 
seen all of this before.

To conclude: Adding out-of-process plugin support has really nothing to 
do with 'bloating XFCE' - btw. why does everybody wants to use this 
terribly stupid marketing slang? - but instead its really needed and 
will improve the stability of the panel and open the door for new 
plugins that wouldn't be possible currently (atleast not w/o major hacks).

And a quick note on the memory usage: The memory usage of a plugin 
running within the process of the panel and a plugin running outside of 
the panel is mostly the same. There's only the overhead of the 
duplicated data sections and the dynamically allocated memory of Gtk. 
GObject/Gtk are being optimized to reduce the dynamically allocated 
memory per process. So, in the future there's only very little overhead 
in the user-space, which is most probably meaningless as we are talking 
about non-trivial plugins, which itself consume a lot of system 
resources itself anyway.

Benedikt