[AD] [Unix] Using pthreads

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Hi guys,

I've started putting in some code to use pthreads under Unix.
The configure script now detects whether the library is
available, and if it is then the X code puts all the event
handling into a separate thread.  If it is not available,
the SIGALRM code is hooked to simulate it.

This is not complete, but it does work and I wanted to make it
available in case anyone else wants to have a look.  I branched
the repository to avoid polluting a stable version with
relatively unstable code -- to get on to this branch, do:

    cvs update -r unix-pthreads

After this, you'll always be on this branch until you clear your
sticky tags -- "cvs update -A" should do it, or "cvs update -r
HEAD".  Or read the manual. :)  When this is stabilised, we can
merge it back into the main branch.


Some issues about these changes:

    * The X event handling is a fairly large chunk of code, and 
      it may have thread-safety issues.  I glanced through it,
      and didn't see anything obvious, but I didn't look yet at
      the DGA2 code.

    * Input callbacks (keyboard and mouse) and the close-button
      callback will now be called by this background thread, not
      the main thread.  In addition, various hooks may be called
      from this thread too, in particular the window redraw
      hook.  AllegroGL probably won't work with this version, I
      haven't tried it yet.  (But if it does work, it won't need
      allegro_gl_begin any more!)

    * The timer is still using SIGALRM for now; this is partly
      to avoid calling the user's callbacks from the wrong
      thread (timer callbacks are a lot more common than the
      other callbacks), and partly because I was too lazy and
      I've been programming at work all day and at home all
      night.

    * The Linux input code is also unaffected -- I only
      converted the X version.

    * The background thread is probably eating a lot of CPU
      time -- there is a yield in it, but I don't trust it to be
      making a huge difference.

    * When threading is not available, the display locking
      system resides entirely within xwin.c now -- SIGALRM
      interrupts will still fire, but xwin.c will ignore them
      rather than relying on the SIGALRM handler to do this.  It
      makes more sense this way because of how the threaded
      version works.  So, xwin.c doesn't call DISABLE/ENABLE any
      more -- it has its own macros, LOCK and UNLOCK, which
      either use Xlib to lock the X display connection or, when
      not using threads, perform a simple semaphore around the
      _xwin_handle_events code.  This isn't really new, it's
      just moved from the SIGALRM handler to the X code.


Further plans:

    * Convert the Linux input code.

    * Extend the class to have enough methods to swallow the
      SIGALRM handling code.

    * Try out AllegroGL with this system. :)


Please let me know, anyone who tries it -- especially if it
doesn't work!

George

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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/