multithreaded callbacks (was Re: [AD] de fourium pointium ohium)

[Peter Wang <tjaden@xxxxxxxxxx>]

On 11 Jul 2001, Eric Botcazou <ebotcazou@xxxxxxxxxx> wrote:
> The "reference" thread is "Multithreading timers" on the [AL] list dated
> 04/12.

Ok.  The alternatives presented in that thread were:

(0) pause the main thread when timer (etc.) callbacks are running

(1) introduce a minimal synchronisation API for timers.  Either:

    (a) the user is in charge of creating, locking, unlocking, and
    destroying mutexes;

    (b) `END_OF_FUNCTION' and `END_OF_STATIC_FUNCTION' and
    `install_int' together implicitly create a mutex when necessary,
    and then `LOCK_MUTEX' and `UNLOCK_MUTEX' are called explicitly
    by the user.  Exactly one mutex per callback.

(2) tell the user that timer callbacks may run in a different
thread, so they should use some sort of synchronisation, but don't
actually provide anything.


My thoughts:

(0) is good because it means _all_ old DOS code ported to non-DOS
platforms will still be correct.  Otherwise it's not very nice, and
has problems associated with it.

(1 a) is my preference.  Personally I like the API Eric suggested
(create_mutex, destroy_mutex, lock_mutex, unlock_mutex), which is
much like the bitmap API.  Under platforms that don't need it, these
functions would do nothing.

(1 b) is okay, but I don't like it much.  Not enough control, and
sometimes you just don't need the mutexes (e.g. increment a game
speed counter).

(2) conflicts with Allegro's cross-platform nature, I think.
Besides, most ports are or will be multithreaded, so we should stop
pretending that we are using hardware interrupts.  Yes, we follow
the DOS port wherever it goes, but supporting DOS is sometimes
really hard or impossible (networked games, AllegroGL games, etc.).
If a game cannot support DOS for whatever reason, it should be
allowed to do slightly more complicated stuff in its callbacks.
OTOH, once people figure out they can do complicated stuff in
callbacks, they might drop DOS support...