|Did you know ...
|Multithreading and the XPCE graphics system
GUI applications written in XPCE can benefit from Prolog threads if they need to do expensive computations that would otherwise block the UI. The XPCE message passing system is guarded with a single mutex, which synchronises both access from Prolog and activation through the GUI. In MS-Windows, GUI events are processed by the thread that created the window in which the event occurred, whereas in Unix/X11 they are processed by the thread that dispatches messages. In practice, the most feasible approach to graphical Prolog implementations is to control XPCE from a single thread and deploy other threads for (long) computations.
Traditionally, XPCE runs in the foreground (
thread. We are working towards a situation where XPCE can run
comfortably in a separate thread. A separate XPCE thread can be created
It is also possible to create this thread as the
is loaded by setting the xpce_threaded to
Threads other than the thread in which XPCE runs are provided with two predicates to communicate with XPCE.
Note that in_pce_thread_sync/1
is expensive because it requires copying and thread communication. For
in_pce_thread_synctrue runs at approximately
50,000 calls per second (AMD Phenom 9600B, Ubuntu 11.04).
pce for XPCE
event handling. In the X11 version this call creates a thread that
executes the X11 event-dispatch loop. In MS-Windows it creates a thread
that executes a windows event-dispatch loop. The XPCE event-handling
thread has the alias
pce. Options specifies the
thread attributes as thread_create/3.