A number of design decisions went into the GPK library. This page explains
how the library is designed and some of the rationale for it.
GPK Architecture
- GPK consists of 3 parts:
- A GTK thread proxy
- A queue thru which the thread proxy gets its work, and
- Wrapper routines for both the client and server thread
sides of the request.
- Below is a schematic of the GPK architecture:
- Application threads that wish to make GTK calls use the GPK
library to have their requests proxied to the dedicated GTK
thread thru a thread-safe queue. GSK or the General Server Kit
is a library of routines that packages function parameters
as pointers to get them across the queue. More about this later.
GSK is a modification of part of Tom Bech's GCK, the General
Convenience Kit. GCK makes using GTK a little easier by
combining commonly used combinations of GTK calls together
in a single call. This is a plus here as it reduces the
number of calls that must be proxied.
- The GTK thread proxy at the right side of the picture sits in
the standard GTK event loop waiting for requests. But before it
entered gtk_main(), a call to gpk_init() was made to prepare
it to also listen to requests from the queue.
Design Goals
-
- No explicit use of locking required to use the library.
- Fairly resiliant to changes to GTK, such as minor
modifications to the API or the addition of widgets
- Low overhead
|
