FYI: 4.7 panel and plugins
Brian J. Tarricone
brian at tarricone.org
Wed May 27 03:51:23 CEST 2009
Nick Schermer wrote:
> 2009/5/26 Brian J. Tarricone <bjt23 at cornell.edu>:
>>> making external plugins
>>> a binary is crap, simply because it can never provide all the
>>> functionality a wrapper can provide.
>> Such as?
> A lot, some on man, you think i'm stupid?
Don't put words in my mouth. It only makes you sound like you're trying
to pick a fight for no reason.
> There is over 900 lines of code in the wrapper.
How am I supposed to know that? After 5 minutes of clicking through
panel trunk, I don't see it anywhere.
> Of course you can all stuff this in a macro and
> dump it in the external plugin. Then each time a new panel is release
> all external plugins have to be recompiled to get the fixes.
Sure, I'll buy that, that makes sense.
> All possible, 1 problem: I decided (on my own) not to do that.
Problem? Not sure I understand what you're saying here.
>>> Internal plugins are a lot faster.
>> Do you have benchmarking results to verify this? Are they faster in ways
>> that actually matter (e.g., is response to user input noticeably faster as
>> internal plugins)?
> Changes to the panel (dbus delay),
Is this noticeable to users? What kind of communication needs to happen
on a regular basis in critical paths where the user will notice the
difference in a negative way? I'd think a user would expect adding a
plugin wouldn't be instantaneous, so, say, a 15% increase in the time it
takes to add a plugin internal vs. external wouldn't be a big deal.
Other things, like saving config, etc., should happen in the background,
so it doesn't really matter if they're slow or not since UI shouldn't
> startup is slower (can only start
> the wrappers if the panel is realized).
Again: how much slower? Is it a huge increase?
>>> If a plugin is stable and does
>>> nothing that might lock the main thread for a long time (no http stuff
>>> for example), I prefer a plugin to be internal.
>> That's kinda hilarious. Show me a stable plugin, and I'm sure you can find
>> crash bugs if you look hard enough. Encouraging plugins to be internal is a
>> huge step backward for stability.
> And then what, if a plugin crashes the panel, it will be simply
> restarted by the session manager.
Wow, your answer to a robustness argument is "if a major part of the
desktop crashes, it'll get restarted automatically"? Unbelievable.
Sure, SmRestartImmediately exists because we all know that software
isn't perfect, but it's more of a "last resort" robustness tool than
> At least you _can_ make it internal,
> you don't have to. And if it's stable, why not. I can even add a
> "i-am-a-wimp" boolean property that forces all plugins to run in a
> wrapper if you want?
That would be great. Would also be an interesting performance
experiment. You should have done this anyway, while investigating
alternatives, instead of just deciding your new way was better.
>>> Internal == in-process, use less memory, faster communication with the
>> Probably not. Processes are pretty lightweight these days.
> Pretty yeah. You make a big deal of (possibly) slower plugins because
> of a call to g_thread_init,
Startup *will* be slower due to linking in libpthread. Many standard
library calls *will* be slower due to extra (unneeded) locking and
running slower threadsafe versions. This is fact. Go read the
NPTL/libpthread source code if you don't believe me (or the old
LinuxThreads source code, if you really want a headache).
> but the extra mb's of memory usage and dbus delay: no big deal.
The problem I have is that you are assuming that these are problems
without checking. Sure, doing an IPC call is slower than an in-process
library call. Duh. But in what cases does this matter?
How much actual *unsharable* memory does having plugins in separate
processes use? Yes, glib/gobject/gtk does allocate some memory on init
that you can't share between processes, but how much?
Regardless, I see no reason why I can't care about one of these issues
but not the other. Allowing a plugin to call g_thread_init() or not
(rather than forcing it always) is an easy optimisation that actually
does have measurable results (if you read through that link you posted,
and clicked through to the mailing list discussion that prompted the
blog post, the side-effects of linking in libpthread are discussed).
And besides, you're talking about creating this wrapper in order to make
the plugin interface richer and more flexible... and yet in the process
you *removed* a useful bit of functionality. That seems
counter-intuitive, and the fact that you added the preinit functionality
back so quickly seems to indicate that it wasn't difficult and is
generally useful anyway.
As for the dbus overhead or extra memory use, I'm usually *quite* happy
to pay slight performance/resource usage penalties in the name of
stability and robustness.
> I doubt you have a strong opinion about all this.
Again: don't put words in my mouth. If I didn't have a strong opinion,
I wouldn't bother continuing to follow up about it.
> I on the other hand have: easy to maintain code base, which (as
> a side affect) resulted in transparency between internal and external
> plugins (which is nice i think, it means plugins are stupid and don't
> contain any code that is handled by the panel). Unfortunately in this
> world you cannot only have good things and you have to life with some
> side-affects, if this case a preinit call and new Makefiles (if i
> can't get the old external plugins running).
True, you certainly can't always have everything perfect and elegant.
But hiding the distinctions between an internal and external plugin
sounds quite similar to the folly of trying to make in-process
communication look exactly like IPC from an API standpoint.
 A folly I once believed in, but was sharply corrected by someone who
knows a lot more about it than I do. See e.g.
More information about the Xfce4-dev