On Tue, 2007-05-08 at 03:33 -0500, Hans Petter Jansson wrote: > I'm used to three main design patterns: > > 1) Everything in one thread with sync I/O blocking the UI. Simple code > but unacceptable performance. > > 2) Everything in one thread with async I/O using callbacks. Fine for > simple protocols or if you prefer an explicit state machine. > > 3) Doing synchronous I/O operations in one or more subthreads that talk > to the main thread using asynchronous messages queues. This is nice for > complex protocol implementations, because synchronous code is easier to > understand and maintain.
These are the main model i see too. But none of these need any main context but the default mainloop one... I know Benjamin mentioned multiple contexts was needed for gstreamer integration. It would be nice to hear some details about this > I'm aware of the dangers - when I worked on Evolution, this caused > plenty of pain. > > However, it's useful in very simple apps where you have e.g. a "Sync" or > "Connect" button which desensitizes most of the UI while the operation > is in progress, only updating a progress bar or allowing the user to hit > "Cancel". That's what I meant by a "program that lends itself to that > design" above :) > > So I dunno. Maybe it's too seductive and should be eliminated as an > option. Avoiding this problem is one of the primary reasons of going from a stateless model (where you can get auth callbacks anytime) to a statefull model (auth only on mount). However, that problem in gnome-vfs happens for *all* apps, not only those that "lend itself to that design", so its a larger problem there. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc [EMAIL PROTECTED] [EMAIL PROTECTED] He's an ungodly native American paramedic on the hunt for the last specimen of a great and near-mythical creature. She's a wealthy mutant opera singer from the wrong side of the tracks. They fight crime! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list