[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-app-devel
Subject:    Re: threading choices
From:       Paul Pogonyshev <pogonyshev () gmx ! net>
Date:       2010-03-02 19:17:59
Message-ID: 201003022118.00312.pogonyshev () gmx ! net
[Download RAW message or body]

Olivier Sessink wrote:
> it seems that are two (or more) choices how to work with threads in
> gtk. You can #1 use a global lock and call gtk from any thread, or you
> can #2 limit your gtk calls to the main loop and not use the global
> lock. As far as I understood, method #2 is portable to win32, and
> method #1 is not? Is that correct? What are other reasons to choose
> for one of these approaches? Are there any other important approaches
> that need attention?

Don't know about Windows, but method #2 is generally regarded as
"saner" approach.  It involves delegating GUI work to the main thread
with g_idle_add().  Depending on amount of such delegation you need
and your language of choice (lambdas and inline functions help) this
may or may not be too tedious.  This approach can also influence your
design choices so that secondary threads emphasize CPU-intensive work
and the main thread mainly serves as a dispatcher of such tasks and is
otherwise GUI-only.

Note that the first method is often not too handy either as
practically all GUI code that can ever be called from non-main thread
needs to be sprinkled with enter/leave.  If your programming language
uses exceptions, remember that leave() call should be inside
try..finally cleanup, else this will cause deadlocks if an exception
is thrown in-between.

Paul
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]