Hi,
On Thu, Oct 21, 2010 at 6:30 PM, Havoc Pennington <h...@pobox.com> wrote:
> 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)
If you believe that the GUI thread should never perform blocking IO
(such as reading from disk or IPC) or never perform CPU-intensive
tasks (such as image- or video-decoding) then... then all that your
code in the GUI thread does, is to receive data from one thread and
maybe signal another thread. Additionally, if you arrange for things
like download tasks (which might return a storm of events if you have
a fat pipe) to happen in a separate threads... then you end up not
doing a lot of stuff in your GUI thread - basically only reacting to
external stimuli (e.g. X11 events and maybe some D-Bus IPC).
There's a couple assumptions in the above paragraph of what the GUI
thread should and should not be doing. There's also a built-in
assumption that threading Is A Good Thing(tm) and that it's easy to
use threading (which I believe it now is with libgio - I don't know
about video- or image-decoding). Those are assumptions that I
personally think are sound for the Linux desktop... but I won't be
surprised if some people don't agree.
Anyway, my point really was something like this: If you want to talk
about smooth animations and synchronoizing to vblank, it would
probably be good for GPeriodic, Clutter and GTK+ to specify what
people should and shouldn't be doing in the "GUI Thread".... I know a
lot of it is obvious to people on this list but it never hurts to
write it down anyway.
David
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
