Hi, On Thu, Oct 21, 2010 at 5:47 PM, David Zeuthen <zeut...@gmail.com> wrote: > Note that with GDBus the resulting GDBusMessage is actually being > built in a separate (and private) thread - so in practice there is > zero overhead in the GUI thread - in particular it doesn't depend on > what kind of message it is or how big the message is. The same is true > for most of libgio's file and networking primitives (e.g. > g_file_load_contents_async() will cause work to happen in a worker > thread etc.).
I don't think this matters as long as there's effectively a queue in the main thread (i.e. each message or IO chunk has a handler in the main thread). If you dispatch once per dbus message from an X-priority main loop source, then lower-than-X-priority handlers will not run until there are no dbus messages available. So if you are getting flooded with messages, for example if a stream of data is being dbus-transmitted, you would need to chew through that whole stream - _or_ it would have to just happen that on one iteration of the main loop the message processing had caught up with the message sending and the queue was empty. Moreover that iteration would have to happen to have no other X-priority sources ready. In that case a lower-than-X-priority dispatch could occur. As the number of X-priority sources goes up (think big complex app with plugins) the odds of getting no X-priority sources on a given iteration would presumably drop. As long as the main loop is seeing a stream of items with no guaranteed pauses in the stream, in theory that main loop source runs unbounded. (yes, in practice it usually doesn't run unbounded, but I bet trying to hold 60fps will make the in-practice glitches more visible) Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
