Re: GModule unloading

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

 



On 5/23/07, Michael Ekstrand <mekstran@xxxxxxxxxxxxxxx> wrote:
> On Wed, 2007-05-23 at 10:18 -0500, Matt Hoosier wrote:
> > On 5/23/07, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> 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.
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux