Re: Doubts about GPeriodic

[Havoc Pennington <hp pobox com>]

Hi,

On Thu, Oct 21, 2010 at 5:47 PM, David Zeuthen <zeuthen 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