Re: [AD] Allegro 4.2 todos

[Angelo Mottola <a.mottola@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, I see. Then probably the best solution for now is to leave things as
they are.

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

Ok, but then the test (and other programs/example) randomness problem is not
solved again... Should we add a dedicated static rand() function at least to
the test program? The various tests is where the low randomness shows the
most.

-- 
Angelo Mottola
a.mottola@xxxxxxxxxx