Re: [AD] Allegro 4.2 todos

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> Could you quickly refresh my mind on what the exact problem is? I'm too
> lazy to search the ml archives myself :P

The library is simply not thread-safe, while it uses several threads on most 
platforms. More specifically, operations performed within callbacks can be 
interrupted by a context switch and are not protected against that. See Sam 
Hocevar's bug report on 05/13 and many others.

> I suppose such a driver will sit near and not replace the existing ALSA
> 0.5 one, otherwise the QNX port will have some problems...

The QNX port has already some problems, since in 6.2 they have departed from 
ALSA and now use QSA (QNX Sound Architecture!) which is
almost-ALSA-but-not-quite, different enough to break the current driver. But 
I agree that we shoud keep ALSA 0.5.x anyway.

> - removed textout_ex and similar function and modify default textout
> behaviour so I we don't have those "function is deprecated" warnings
> anymore (yes, binary compatibility would be broken, but still this is a
> major release)

Not only binary, but source compatibility will be broken. And we are commited 
to not breaking it (see api.html).

> - maybe start to remove some redundant function like draw_sprite (not
> really sure here though)

Neither.

> - integrate OpenGL drivers where natively supported (and via Mesa
> otherwise), from AllegroGL (heresy?)

IMHO that's too late, we should have decided it right after releasing 4.0.0 
if we really wanted to add it for the 4.2 series. But Bob can certainly give 
more useful infos on that.

> - this has already been proposed, but I'll launch it again: what about a
> little public multiplatform threading API, sitting near the already
> existent mutex one? Threads are useful in games, despite some of you may
> think.

We tried but we hit a big problem: we couldn't devise a semantics for 
synchronization functions (mutexes) that is consistent on multi-threaded 
ports as well as DOS and Unix w/o threads. Again callbacks.

> I can think of #1, but it seems to me we didn't come to a decision on how
> to operate: the best solution so far IMO is the one to include a *private*
> _al_rand() function that works like rand() but uses a dedicated algorithm
> (not a complex one; the 4-5 lines snippet appeared a while ago would
> already fit nicely to me).

In Paul Pridham's message dated 05/26.

> If this is ok, I can add it and replace rand() calls everywhere in the
> library. Let me know!

Yes, I think that's the solution everyone seems to agree to, so you can go 
ahead.

-- 
Eric Botcazou