Re: GEMDOS re-entrancy

[Christian Lynbech <lynbech@daimi.aau.dk>]

>>>>> "Warwick" == Warwick Allison <warwick@cs.uq.oz.au> writes:

Warwick> ekl@sdf.lonestar.org (Evan K. Langlois):
>>  Question, why AES and VDI?  Well, they are the same trap for one.
>> And I thought the calls were executed in supervisor mode so that
>> they couldn't be re-entered anyway.  And isn't the VDI re-entrant?
>> Hmm .. maybe not since you can't call the AES from a G_USERDEF
>> object.


Warwick> WHICH VDI?  NVDI and Nova VDI spring to mind, and the
Warwick> Cybercube boards' VDI.

Warwick> To me, the question really is, why would you want AES and VDI
Warwick> to be reentrant?

Warwick> X11 doesn't draw anything in parallel.

There is one snag, when talking about GEM (that is AES and VDI). If
GEM is not reentrant, one process should block GEM while executing a
GEM function. That is no problem for graphics, it takes the time it
takes anyway, but dont forget the event loop. The typical GEM program
will call an event_something and block GEM for a very long time!

Reentrancy is one solution, another would be to have some server
thingy, such that GEM thinks there is only two GEM programs in the
system (I remember having seen that AES is reentrant to three levels),
one of which never calls event_anything. Then clients (!) could send
request to the server which would use GEM messages to forward it to a
dispatcher process, which would otherwise be suspended in GEM waiting
for the union of all requested events (plus the server messages of
course), shipping back events to the server whenever one occurred.

A pretty complicated alternative to MultiAES, but should be a workable
solution. One could even start enhancing things as all calls goes
through a server, adding things like X style keyboard handling,
network support etc.



------------------------------------------------------------------------------
Christian Lynbech               | Hit the philistines three times over the 
office: R0.33 (phone: 3217)	| head with the Elisp reference manual.
email: lynbech@daimi.aau.dk	|        - petonic@hal.com (Michael A. Petonic)
------------------------------------------------------------------------------