[MiNT] kqueue() vs. gemdos xdd

["Evan K. Langlois" <Evan@CoolRunningConcepts.com>]

Well,

I've done a  lot of reading on kqueue.   Very nice interface!

My current opinion is that its perfect for large servers, but I'm not so sure about MiNT/AES programs.  It will certainly handle 4000 descriptors very efficiently, especially if most of those aren't active, but what about the typical case of 1 AES file descriptor, possibly while loading or saving another file?   Is it the most efficient in this case?  What about the overhead of generating all the knotes and searching through them during events?  It would seem that every part of the system that could generate an event has to tell every filter that has a knote installed to see if that filter should generate an event for the knote.   This seems like it could add up in the long run.

Secondly, its unclear how well the AES would fit into the kqueue() mechanism.  For example, take evnt_multi() ... how do you pass in and out all that information?  If you use the user pointer to point to an array then the application programmer can't use it.  Are the events still to be a bitmask, or do we make each possible AES event a single kqueue() event?   From a programmer standpoint, making them all seperate events allow better use of the user pointer for each event, and it seems a better 1:1 mapping.  However, some things like button state, keyboard state, and things of that sort that the AES tells you, you would want to know for each event and so reporting that with each event could get redundant if many events come in at once ... hmm ... I suppose that isn't likely though.  Under heavy multitasking how many knotes() will be sitting around in the list (especially if each AES event has a separate knote, you could have quite a few per application)?  

Third, it seems like a big piece of code.  I haven't looked to see how many places in the kernel it would touch, but it seems like it could be a lot to debug and test, especially when the AES part is still in the process of being debugged and tested.  Also, I didn't see anything in there that Kqueue() could do that you couldn't do some other way, and if the AES were simply a filter in Kqueue(), you'd really be locked into using Kqueue.

Now, my original example of making the AES a device driver seems like it would be a bit more localized as it would be compartmentalized into a single device driver.   The device driver approach seems like it would be quicker to implement, and the user application programmer would use GEMDOS, which is more familiar to Atari programmers ... kqueue isn't.   Most apps could implement evnt_multi() with a single blocking Fread() and if Fcntl() isn't good for setting the events you are interested in, perhaps writing to the driver with Fwrite() is better.  That approach isn't available under Kqueue (that I can see) and it could be beneficial for sending long AES messages.  

The AES knows which application it wants to send an event to, so it would just be a matter of sending the data to the right fd (and by reading the event with Fread() we can attach quite a bit of data to the event, possibly precede the data by the size of the event data to be read).  This would be compatible with Fselect(), blocking Fread(), Fpoll(), as well as Kqueue() and/or Epoll() or an extended Fselect() that can handle more file handles or whatever is decided to add in the future.  This doesn't rule out the use of Kqueue(), it just makes the AES a GEMDOS fd instead of a special filter so that mechanisms other than Kqueue() can be used.

Making trap #2 a wrapper around either GEMDOS calls or around Kqueue() is a separate issue, and I think there would be a benefit to making both old and new APIs have the same kernel entry points and go through the same code paths.   It shouldn't be all that intensive to do either providing the equivalent "new" method of performing the same operation is well documented.

Speaking of which, would anyone be willing to work on a documentation wiki?   The Atari Compendium seems like its still the most complete document for all the OS calls, and it was relatively buggy and in some cases just plain wrong or left out really important details (like not mentioning how to wait for a change in any mouse button with the 0x0100 flag) and its now relatively outdated as well.  A wiki could let anyone update the documentation at any time.  I'd be willing to host it.

Thanks,
Evan Langlois
aka Taro