Re: GEMDOS re-entrancy

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

> ========================================================================
> 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
> ========================================================================
> 
> Question, why AES and VDI?

- Process A calls rsrc_load(), enters GEMDOS and the HD driver.

- HD driver sets up transfer, puts process A to sleep (inside a GEMDOS
  call inside an AES call)

- Process B calls AES and may crash since AES isn't reentrant - even
  if B doesn't call something that causes files to be accessed

A similar story applies to the VDI. (Just think about loading
fonts.)

So my vote is: Block GEMDOS, AES and VDI for a first attempt. It
will still prove to be useful, and I could at least add some
kind of background transfer into the driver and have it tested.

BTW: I would be interested how all this will be done in Mag!X.
I hear that they are working on all those things that we are still
just discussing. D*mn, how I wish we could somehow merge MiNT
and Mag!X...

> Semaphores are nice in the right place, when you just want to do nothing
> if some other process owns the semaphore, but we want to do something 
> special, so in effect, the GEMDOS trap would become the semaphore.

Aren't semaphores supposed to put all requesting processes to sleep
until someone frees the semaphore? That would be the exact equivalent
to what you propose, without the need to change trap vectors.

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