[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] State of the Union



Hello!

I'll paraphrase.  Basically, I was asking if there was an "approved"
solution for an integrated event loop to handle both AES and GEMDOS
style events, and what that solution was.  Also, if there is no such
"official" solution yet, I was suggesting my own.

The suggestion, to simply a whole page of information and various
reasons for this idea, is to use a device to feed AES events to GEM
applications.   This removes much of the problems you would have with a
pipe, although a socket would still be an alternative, I like the device
idea better.  You can tell this device what sort of events you want with
Fcntl() calls, and then simply wait on the opened file handle.

Ah, I see. Personally I wanted to go into the kqueue() direction as introduced and used by the BSD systems. This solution looks very easy to use and is extremly flexible and extensible. It's basically a filedescriptor and you add a list of events (determined by id and a filter) you want to wait for.

I further suggested that to implement this cleanly, the entire AES could
be represented as a wrapper library around GEMDOS calls that talk to the
device driver.  For example, appl_init() might open the device and get
the file handle, appl_exit() would close it, evnt_multi() would set
parameters and read from the device file handle and write into the
supplied return values, etc.

Yes, this can be done. But the questions is if it's necessary. For backward compatibility you have to provide the old API anyway and if you want to use the new features you need to define a new API.


Regards,
Frank

--
ATARI FALCON 060 // MILAN 060
-----------------------------------------
http://www.cs.uni-magdeburg.de/~fnaumann/
e-Mail: fnaumann@freemint.de