Re: Help: multithreaded GNOME app

[James Henstridge <james daa com au>]

That code is particularly old, and probably won't work with 1.1 series of
gtk.  Why don't you use the threading support built into GTK with the
gdk_threads_enter and gdk_threads_leave function calls (the idea is you
put these function calls round code that uses GTK in each thread.

James Henstridge.

--
Email: james@daa.com.au
WWW:   http://www.daa.com.au/~james/


On Tue, 2 Feb 1999, Roy Wood wrote:

> If you're interested in multi-threaded GTK apps, go here:
> 
> http://www.humanfactor.com/gpk/
> 
> 
> 
> GPK is an addon library to permit thread-safe access to GTK. It is used 
> in conjunction with POSIX threads and GTK 0.99.1 and higher.
> 
> 
> Motivation
> 
> GPK was developed as a solution for a GTK-based application I am writing 
> for measuring web server performance. By its nature, the application is 
> heavily threaded and individual threads need to make "real time" updates 
> to the GUI as it progresses. After looking at many approaches, I finally 
> settled on one. GPK is the result of the effort to implement this one 
> design and make it reusable by the GTK community.
> 
> A more complete discussion of the benefits and pitfalls of threads is 
> available on the GTK and Pthreads page.
> 
> The Problem
> 
> Developing multithreaded GUI applications for X-Windows can be a real 
> challenge. Most X-Windows development toolkits, such as Motif 2.0, 
> Athena, GTK, OpenLook and others are not thread-safe. In addition, the 
> supporting X libraries themselves may not thread-safe.
> 
> Each of these libraries are examples of event loop programming, where 
> much of the state of the application is maintained in library's data 
> structures. But one of the principle structural advantages of threaded 
> programs is the ability to maintain transitional state information 
> directly within the state of each of the threads. This contrast means 
> that integrating threads with event-driven libraries can be difficult. 
> The bottom line: multiple threads cannot always work simultaneously with 
> X-Windows based libraries and toolkits.
> 
> A Solution
> 
> One solution to this problem is to dedicate a single thread to 
> maintaining the GUI and have other threads send it requests. Because this 
> thread is doing work on behalf of another, it is called a proxy thread. 
> Keeping the event-loop libraries confined to a single proxy thread, and 
> performing long running operations in separate threads provides both a 
> safe and more responsive solution.
> 
> GPK or the General Proxy Kit (for lack of better name) is a library that 
> turns the main GTK event loop thread into a server thread that listens 
> for requests from other threads. The GPK Architecture page details the 
> design of the GPK proxy system.
> 
> How Do I Use It?
> 
> Using the library is straightforward: Have the thread that will run int 
> the gtk_main() event loop call gpk_init() prior to entering the loop. Use 
> any gpk_ call from the library from any thread (including the GTK main 
> thread) to perform any GUI operation provided. Callbacks (running of 
> course in the GTK event loop thread) can also call GPK routines safely. 
> GPK will detect that the request is a proxy to itself and will execute 
> the command on the spot.
> 
> To aid in understanding the usage of GPK, a Using GPK page is provided. A 
> sample application called PerfMon is included.
> 
> With the help of users, GPK will hopefully be expanded over time to 
> include more of the full function of GTK. Today it provides access to 
> commonly used collections of functions. 
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>