FYI: 4.7 panel and plugins

[Brian J. Tarricone]

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 
get blocked.

> 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 
anything else.

> 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
>>> panel.
 >>
>> 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[1].

	-brian

[1] 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. 
http://research.sun.com/techrep/1994/abstract-29.html