Hello!
Select and poll() never win, unless you are writing your program in reverse. Maybe you are missing out in how an event driven program works. I don't want to check if something happened on file descriptor #5. I NEVER have to iterate through the returned structures looking for descriptor #5. This is where your logic breaks and why the existing stuff doesn't work for you. Userland isn't doing any linear searches!
Just as note: I think this depend on the type of the application. I don't think you can say in general how an application works :-)
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.I'm interested in what other ideas you have on solving the "unified event loop" situation. I've already pitched one idea, but not yet heard specifically where the problems are that need to be redesigned.
You got me wrong. I meant that it's not strictly necessary to wrap appl_init, appl_exit and these things around a new interface because you have to provide the old API for compatibility anyway. And using new features require always a new API.
For example, should AES events come through a GEMDOS handle (as I mentioned), or should GEMDOS file handles be a special form of AES event (the expanded evnt_multi approach), or should they be on equal ground, both coming from a more flexible interface?
My suggestion (for the new API) is a central, unified kernel event interface for all types of events.
Regards, Frank -- ATARI FALCON 060 // MILAN 060 ----------------------------------------- http://www.cs.uni-magdeburg.de/~fnaumann/ e-Mail: fnaumann@freemint.de