Re: GEMDOS re-entrancy

[Howard Chu <howard@harry.lloyd.com>]

  ========================================================================
  - HD driver initiates transfer, puts process A to sleep. Note that
    process A is now sleeping *inside* GEMDOS.
  
  - Process B makes a GEMDOS call.
  ========================================================================
  
  It would seem there are 3 choices.
  
  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.
  
  I'd rather make GEMDOS re-entrant, but failing that perhaps option 3 could
  be implemented?
  
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?