[AD] X: using threads for asynchronous activity

[George Foot <gfoot@xxxxxxxxxx>]

Currently, X Allegro (and Linux Allegro, but X is my concern at
the moment) uses a SIGALRM handler to do things in the
background.  This means that every 10ms (or however often the OS
feels like calling us) we check for events in the X event queue
(and call user timer handlers).

This causes problems when X events are being polled from the
signal handler when it has interrupted an X command in the main
code -- the data of the two commands gets mixed up on its way to
the X server.  Michael's current solution is to require the main
code to disable the SIGALRM handler while it executes X
functions.

An alternative is to use Xlib's XInitThreads, XLockDisplay,
XUnlockDisplay functions.  The idea here is that one thread can
lock a display connection while it uses it and then unlock it
afterwards.  If it was already in use, XLockDisplay will wait
for the previous user to release it.

These can't be used by the code in its current state, because
when the main code has locked the display and the signal handler
kicks in, the signal handle will sit waiting for XLockDisplay to
return -- but it will never return because the main code has
been interrupted and will not continue until the signal handler
finishes.  If we could use a non-blocking version of
XLockDisplay, which would return immediately if the display was
already locked, then we'd be able to do this, but as it stands
it can't work.

If, however, we do all the asynchronous work in a separate
thread, then we can use these functions.  It may also be a good
idea to move the timer code into another thread too -- we might
get better accuracy.  The problem with this is that we'd require
pthreads, or we'd have to have a fallback plan to deal with
systems that don't have pthreads.

So, does anyone have any opinions on whether we should move X
Allegro to a threaded system?  I think making it support both
threaded and non-threaded systems would probably be too
complicated to be worthwhile, but it may be possible.

Of course, if you combine this email with the previous one, my
next suggestion may be to do just the Expose and ClientMessage
handling in the second thread, and use a second display
connection for input handling.  This may have some advantages in
terms of callback routines (is it morally OK to call a user's
callback from a different thread?) but it would mean preserving
the somewhat messy use of SIGALRM.  Overall I think if we go
threaded we might as well do it properly.

Hmm, threads are so '90s.  I wonder when they'll be obsolete --
maybe then we can start using them. :)

George

-- 
Random project update:
22/06/2000: AllegroGL documentation:  http://allegrogl.sourceforge.net/
        See under `Documentation' for the AllegroGL Reference Manual in
        various formats.