Re: [AD] Allegro 4.2 todos

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> No, never even thought about dropping it here. I proposed an approach to
> let the user test if the thread support is there, and act accordingly.

Sure, but the result is predictable on DOS: it's no, never ever. So you are 
singling out this port.

> It'd be the same as under DOS or any other platform that doesn't support
> threading: just that install_threads() fails and the program should either
> fail returning an error message or work around the need of
> threads/mutexes.

Do you really think that developers will "work around the need of 
threads/mutexes" ? This is not an easy task and means basically maintaining 
two internal logics.

The current situation has at least one advantage: by not providing a 
threading layer, we effectively discourage the gratuitous use of threads in 
Allegro programs, so we ensure that DOS and Unix w/o threads are not too 
impaired. Now if a developer really want Allegro + threads, he can use 
whatever portable thread libraries he want (e.g. pthreads).

> Humm, you're right. But then we're at the starting point again: we can't
> have it private if we want it in the test program (as first case) and in
> the other apps (examples, etc.). And if we make it public, how to call it?
> al_rand() comes to mind, but then it sounds like an al_ prefixed function
> in an unprefixed library and this is bad IMHO. rand_ex() could fit well
> enough.

We simply don't make it public for the reasons Peter gave. I have reverted 
all the changes outside the core library.

-- 
Eric Botcazou