Re: [AD] Allegro 4.2 todos

[Angelo Mottola <a.mottola@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 don't see an easy solution without rearranging a lot of things. Probably
this is better left as is then since we're going for a change in
architecture in (distant) future Allegro releases.

>> 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.

Heh, too much time has passed since I last booted under QNX...

>> - 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).

Hug. Never bothered to read that file, and now I see I should have done
it... Still, I hate all those "deprecated" warning messages.

>> - 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.

Why are we too late? AllegroGL has been out for a while so it's already
somewhat stable enough (or am I wrong?). Integrating it within Allegro
shouldn't cause much problems as I see it... And we're still 6 months ahead
of the 4.2 release (if we want to give it for the end of the year) so
there'e plenty of time to fix any possible thing.

>> - 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.

What about an install_thread() function, that fails if no threading support
is available? (in which case also mutexes would not work). This would leave
the decision on safely using thread/mutexes up to the programmer...

>> 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.

I have a problem: if I declare it as private inside internal.h, we'll have
to include this header manually also in many files (test.c, demo.c, ex12bit,
ex3buf and others that all use rand()), which is not nice IMO.
Otherwise I could declare it in some basic Allegro header, but then which
one? Noone seems to be the right place for such a function...

-- 
Angelo Mottola
a.mottola@xxxxxxxxxx