Re: [gtkmm] 2 mainloops in 2 different threads?

[MHL Schulze t-online de (Martin Schulze)]

Am 18.09.2002 15:32 schrieb(en) Stephan Puchegger:
> Hi everyone!
>
> Is it possible to have 2 different Glib::MainLoops in 2 different
> threads?
> I think, that this should be possible with glib, but I am not so sure
> about glibmm. I may be mistaken, but I assume, that the static
> member functions in some of the glibmm mainloop classes will not like
> this
> setup. Is this correct?

There is a default main loop which is the main loop that runs from the
initial thread. Some global (convinience) functions in namespace glibmm
work on this default main loop and internally call non-static member
functions of the default main loop. However, what static member functions
do you mean?

> The other thing I am not so sure about is the relationship between the
> gtkmm mainloop and the glibmm mainloop. In gtk+ it is possible to
> substitute a call to gtk_main() with the glib mainloop. The mainloops in
> gtkmm and glibmm wrap the C mainloops in gtk+ and glib. Is it also
> possible to do such a substitution in this case? (general idea (may not
> be
> the best): calling Glib::MainLoop::run() when the main loop is a
> Gtk::Main)

The gtk+ mainloop? gtk_main() constructs a glib mainloop and registers
all callbacks that are needed to work with gtk+ inside the _glib_ mainloop.
It supports nested mainloops.
The gtkmm mainloop is just a wrapper of the gtk+ mainloop. E.g.
Main::iteration() just calls gtk_main_iteration_do(). So working with the 
c++
wrappers doesn't add any extra levels of complication if you need to
manipulate the gtk+ mainloop.
So the short answer is: Yes, the substitution is possible!

> I am trying to write a library, that needs to recursivly call
> the mainloop to wait for certain hardware events and should work with and
> without gtk.

Why don't you use Glib::Dispatcher to signal events to the GUI thread 
(which
runs the default mainloop) from a working thread (which serves the 
hardware)?
Of course you cannot lock the GUI completely this way but a non-reactive
GUI is not very user friendly especially since there is the potential 
danger
of some dead lock so that the GUI never wakes up again!

Regards,

  Martin