On Mon, 15 Nov 2010 12:06:05 -0600 Michael Sierks <[email protected]> wrote: [snip] > Sorry, The thread doesn't have its own main loop. Currently it just > monitors the socket for data to read. Though I could be mistaken, > wouldn't that count as having a main loop ? Using threads seems to be > pretty complicated, I also thought they were necessary for this > application. Should I be using threads like this with a program that > is network intensive ?
To your first question, no. To give a thread its own main loop you need to create a new main context in that thread and then call Glib::MainLoop::run() on it (which will block). The thread then has its own event loop, and to attach sources to it you should pass the Glib::MainContext object as an argument to the relevant function adding the source. As you have coded it (in a thread-unsafe way), it will be your main GUI thread which does the reading. You may or may not need additional threads in your program, and you may or may not need to give your worker threads their own main loop. It depends on what is network intensive and what interaction, if any, you need to make with gtk+. If programming with threads you need to know what you are doing, and it is made more tricky by the fact that libsigc++ is not thread safe, nor are some aspects of glibmm. I have adopted the rule that if I want to do anything in a thread other than the main GUI thread, I don't use glibmm or gtkmm in that other thread, but I use glib/gtk+ directly or use some of the other C++ thread-safe wrappers for glib which are available. In this case I strongly suspect that giomm will do everything you need, and you do not need explicitly to start any new threads on your own account (gio's asynchronous functions will do that for you behind the scenes safely, and I assume that the giomm wrapper for them has wrapped them in a way which respects that). For example you can wait without blocking for a new connection using Gio::SocketListener::accept_async() [1] and once you have a connection you can also read asynchronously with Gio::InputStream::read_async() on the Gio::InputStream object obtained by calling get_input_stream() on the Gio::SocketConnection object returned by Gio::SocketListener::accept_finish(). Chris [1] I notice that this takes a callback of type Gio::SlotAsyncReady. This is not correctly documented and is in fact a typedef for the type sigc::slot<void, Glib::RefPtr<Gio::AsyncResult>&>. _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
