Chris Vine wrote: > On Mon, 8 Sep 2008 23:16:44 +0200 (MEST) > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > I just saw Havoc's blog entry "SYNCHRONOUS IO NEVER OK": > > http://log.ometer.com/2008-09.html#7 > > > > and I wondered if there is a > > http://en.wikipedia.org/wiki/SwingWorker > > like interface in glib to run blocking code outside the glib main loop > > to prevent locking the gtk+ GUI? > > > > Do you guys know an easy solution like SwingWorker for glib? > > You can do non-blocking reads and writes with GIOChannel without having > to start any new threads and it is not much more difficult than > blocking reads - you set it non-blocking with g_io_channel_set_flags(), > plumb it into the main loop with g_io_add_watch() and read whatever > happens to be available in your callback function (until you get > G_IO_STATUS_AGAIN returned on the iochannel read), and keep on doing > that until you reach end of file or you have obtained whatever you were > expecting. At that point you can remove the watch.
The problem is that open() does not have a non-blocking equivalent and when I want to open a NFS file over a slow connection my GUI can block for a long time. So I need to do the open() in another thread anyway. There are lots of other blocking functions in the kernel that do not have a non-blocking equivalent. > However, if you really need blocking reads (not very likely), you can > start a new thread to do the work - see: > > http://library.gnome.org/devel/glib/stable/glib-Threads.html > > You can hand any result back to the main GUI thread with g_idle_add() > (g_idle_add() is thread safe). I would like to have a extremely simple API in glib for doing this kind of blocking calls as easily as possible. Do you guys think a simple API like SwingWorker could be integrated in glib? Ahora también puedes acceder a tu correo Terra desde el móvil. Infórmate pinchando aquí. _______________________________________________ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list