RE: Fw: Re: [AD] messy allegro 5.0 stuff

[Shawn Hargreaves <shargreaves@xxxxxxxxxx>]

Eric Botcazou writes:
> So, using threads internally was only an ad hoc decision to 
> mimic the DOS behaviour ? 

Yup. And the same on Linux. All the DOS code used asynchronous 
callbacks (hardware interrupts), and the API reflected this by 
providing the data in volatile global variables and by 
optionally passing the callbacks onto the user, so other 
platforms didn't have any choice about using threads to mimic 
that behaviour.

Personally I'd find a polling system cleaner (and it would
remove the need for any input-related threads), but I don't
think it matters very much.

> Then I wish Stefan hadn't stepped down from the development,
> because I'd like to ask him why the Windows port was using so 
> many threads (9 in the test program as of the 3.9.34 version !), 
> while 3 could have been enough.

I never looked too hard at what all those threads were doing,
but there certainly did seem to be a lot of them! Probably a
result of just getting all the individual bits working 
separately, and then never sitting down to think through how
any duplicated resources could be shared out better between
multiple tasks.

> I probably missed something during the past month because I 
> thought we have been talking about revamping the API, not 
> redesigning another library. I don't have anything against 
> that, but I would have liked to be informed ;-)

I think that is one of the first things you need to decide:
how much is good to keep, how much could benefit from being
improved, and how much anyone can be bothered to actually
do work of rewriting things :-)

With the DOS-only to portable transition, I found it 
surprisingly easy to make big changes to the structure of
the code without having to rewrite all the details, though.
Eg. with the keyboard stuff, the existing hardware interrupt
handler and scancode conversion pretty much stayed untouched,
even though they ended up in different files and sometimes
split across different functions, with vtables and driver
structures added over the top. So it might be possible to
choose quite a different structure and just change existing
low level stuff to work with a newer framework...


-- 
Shawn