FYI: 4.7 panel and plugins

[Nick Schermer]

2009/5/26 Brian J. Tarricone <bjt23 at cornell.edu>:
> I really hope you'll reconsider this.  Calling g_thread_init() requires that
> a program is linked to libgthread, which requires that the program is linked
> to libpthread.  Libpthread replaces a large number of libc functions with
> (slower) thread-safe versions, which obviously isn't necessary in a
> non-threaded applications.  This also slows app startup since the dynamic
> linker has to work harder (not just to load extra libraries, but to override
> existing symbols in the GST).

Ok will look into this and provide a preinit call, which will only
work for plugins that run external.

> Having plugins not know if they're external or internal is somewhat nice
> from an implementation perspective[1], but this is an abstraction that
> really shouldn't be there.

Well too late, it's something the panel provides for some time now and
not something i'm going to revert.

> On the other hand... is there a need for internal plugins at all?
> Would there be much of a performance/resource usage impact if (for example)
> the launcher plugin was made external?

Internal plugins are a lot faster. 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.

Nick