Planning for for 4.4 panel
benedikt.meurer at unix-ag.uni-siegen.de
Thu Jun 30 23:12:01 CEST 2005
Richard Stellingwerff wrote:
>>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
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
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.
More information about the Xfce4-dev