Re: [AD] Mini-synchronization API proposal for 4.1.x

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> Please do; this ensures API consistency.

Hmm... you're probably not wrong :-)

> I'm not aware if any previous discussions were made on a threading API,
> so if this has already been addressed, please point me to the messages

There was a bit of discussion on this topic when the mini-synchronization
API was first invoked, and I think the consensus was something like: use
Pthreads if you want a portable full-featured threads API.

> (is there a mailing lists archive online?).

Unfortunately not for [AD].

> Currently Allegro messes up a lot with timers/threads. The distinction
> between them is not even coupled in the lib, so on some OS a timer is
> setup as an ISR, while on other OSes timers are handled via a thread,
> and the average user doesn't know whatever his timer really is.

I think the long-term goal is to use threads on every platform except DOS.

> So to avoid the problem of "hidden" threading, I'm proposing to add also
> an AL_THREAD type (Allegro 5 territory?) with a dedicated API to handle
> OS indipendent threading (al_create_thread, al_resume_thread, etc.), and
> to differentiate more interrupt timers from thread timers.

I don't understand here: why to differentiate interrupt timers from thread
timers, given that they are never simultaneously present on a particular
platform ? Unless you want to differentiate them on a platform basis, which
would somewhat break the platform-independent paradigm of Allegro.

> Actually we could cover both them explicitely, so the user can freely
> choose one of them depending on his needs (assuming the choosen one
> is available on the target platform).

But the user can't choose anything with regard to timers ! On DOS, he is
forced to use interrupts; on Windows, threads; on Linux/signals, interrupts;
on Linux/pthreads, threads and so on...

> IMHO exposing the difference between ISRs and threads is a desiderable
> goal, as it forces the user to make distinction between them, thus
> creating proper programs that run as they are supposed to run (no
> unexpected race conditions from a program made by an user ignoring
> Allegro is using a thread somewhere for example).

I think that, given the multi-platform nature of Allegro, the position on
this matter should be to consider the worst case: thread timers, for which
execution of callbacks is not guaranteed to be atomic. Therefore we should
recommend to use the mini-synchronization API (which would compile away to
nothing if it is not needed) for portable code.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx