Chris Vine wrote:> On Mon, 8 Sep 2008 23:16:44 +0200 (MEST)> "DANIELLLANO@xxxxxxxx" <DANIELLLANO@xxxxxxxx> 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 andwhen I want to open a NFS file over a slow connection my GUI can blockfor 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 havea 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 thiskind 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 listgtk-list@xxxxxxxxxxxxx://mail.gnome.org/mailman/listinfo/gtk-list
