Re: GEvent - Proposal for a new threading structure for GLib

On Fri, 2006-11-17 at 11:16 -0500, Matthew Barnes wrote:
> Working full-time on Evolution, I find myself doing a fair amount of
> multi-threaded programming.  I've often wished GLib had something
> equivalent to Python's threading.Event class [1], which is a simple but
> useful mechanism for signaling an event to other threads.
> I'd like to propose such a mechanism for GLib, which I call a GEvent.
> A GEvent manages a mutex-guarded boolean and condition variable.
> Threads can set, test, clear, and block on a GEvent without worrying
> about the details of locking/unlocking or checking a condition variable
> properly.

This seems similar to a class we have in glibmm, Glib::Dispatcher:
though that uses pipes to get some kind of locking for free. I didn't
imlpement it. It's quite popular.

It's definitely a good idea to provide some easy way to implement the 
"only use GTK+ in one thread" rule.

> The most compelling use case I see for this in Evolution is for message
> passing.  Threads that push messages to an asynchronous queue or a
> thread pool are often interested in knowing when the message has been
> processed and its output is available.  A simple way to coordinate this
> would be to embed a GEvent in each message and have the thread
> processing the message set the event when it is finished.  That would
> then wake up any threads that are blocked on the event.
> There's obviously many other use cases.  Any textbook on concurrent
> programming should provide plenty of examples.
> I've attached a patch that implements and documents GEvent.  It closely
> mimics the Python class, so I won't bother describing the API here.
> Would this be a worthwhile addition to GLib?
> Matthew Barnes
> [1]

Murray Cumming
murrayc murrayc com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]