Re: GEMDOS re-entrancy

[Claus Brod <clausb@hpbeo79.bbn.hp.com>]

>   1) GEMDOS must be re-entrant.  It isn't.
>   
>   2) Process B must not make a GEMDOS call.  This could lead to some weird
>      multitasking.  I guess it would work, but halting the AES when a program
>      tries to load fonts could get kinda hairy.  Processes that can't call
>      GEMDOS cannot accept input or display output.  This will work, but it's
>      hairy.
>   
>   3) Make process A sleep OUTSIDE GEMDOS.  There must be some way to clean up
>      GEMDOS while process A sleeps, perhaps exiting GEMDOS and putting the
>      process on some sort of wait queue.  Then have the process re-enter
>      GEMDOS when the IO is complete.  There has GOT to be some way to clean
>      things up.
>   
> Option 3 sounds interesting, but if you look at it, you will still need to
> rewrite portions of GEMDOS to support it, so you might as well do the whole
> thing right with option 1, eh?

Option 2 isn't that hairy as it may seem. It just requires reentrance
semaphores for AES, VDI and GEMDOS. The effect would be that you couldn't
call AES while another process is inside AES, but that's exactly
the same situation as with the current MiNT version. This would
allows not as much parallelism as we might want, but at least a little
bit. Option 2 also doesn't involve lots of kernel hacking which I would
like to refrain from for now.

--clausb@hpbeo79.bbn.hp.com-----------------------------------------------
Claus Brod, MDD, HP Boeblingen         Have you hugged your manager today?
--#include <std_disclaimer>-----------------------------------------------