Re: GModule unloading



On 5/23/07, Michael Ekstrand <mekstran scl ameslab gov> wrote:
On Wed, 2007-05-23 at 10:18 -0500, Matt Hoosier wrote:
> On 5/23/07, Paul Davis <paul linuxaudiosystems com> wrote:
> > On Wed, 2007-05-23 at 09:33 -0500, Matt Hoosier wrote:
> > > What happens when the GModule is unloaded? Does libboo also get
> dumped
> > > because the application itself doesn't directly link against
> > > liboo.so.0.1.2, or does it stay resident forever?
> >
> > its a reasonable question. a prior question, however: why are you
> > worrying about this?
>
> I'm working on an embedded system for which the startup time of Gtk is
> deemed unacceptable for launching auxiliary programs. I was thinking
> about using GModules in a way similar to what the maemo-launcher does:
> call some psdueo_main() function to instantiate the toplevel window of
> each auxiliary "program," then just do a gtk_widget_show() on the
> returned UI control.
>
> Often these things will link against shared libraries which the main
> shell application itself doesn't. So I'm concerned about whether the
> main UI is going to crash when some GType registered during the
> lifetime of a module, is made invalid.

Yeah, it'll crash as soon as anything tries to access the type info.

Idea: can you fork(), and then load the module in a separate process?
The load vs. exec will prevent the load cost of GTK+, but the fork will
let you have each app in its own address space.  Closing can be
terminating the process rather than unloading a module, so you don't
have to worry about any of this.

Thanks for the info about the unloading behavior, Michael.

Isn't that going to cause all kinds of confusion when the child
process is trying to re-use the same socket FD to talk to the X server
and such?

I don't have a big objection to marking every module as permanently
resident. I just needed to know whether that was a technical
requirement or not.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]