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

Re: [MiNT] Fpoll() in GEM programs

Hi! There are two different points of view on this. One with which you would extend AES API and another (my proposed pipes) with which you would make FreeMiNT apps aware of that there is a OS compatible input point _file_ (pipe in this case) where you can detect AES activity. My point is that we can get the functionality without extending event_multi() API as that one is ugly enough already. Well, this is rather phylosophical question: 
* Make the AES which has a SingleTOS design more UNIXish?
OR
* Provide UNIXish way to detect AES events (pipes) and call the good 'old' AES interface afterwards... As I don't like extending event_multi() or creating a new AES API extension (of course you can consider the pipes an API too, but I see it being different) for this I would vote to implement the pipe solution into AES. Standa Frank Naumann writes:
Hello! 
A good AES application should have only 1 waiting point,
which is its central evnt_multi. 
My suggestion would be another event bit: MU_SELECT
and a direct response mode bit: MU_DIRECT_RESPONSE.
if the bit is set and there are no events, evnt_multi exits with
zero event. !!! Unless a timer event is set, in which case the app
is suspended until any event occurs (including of course timer). 
With MU_SELECT you have a way of getting filehandle or socket events
the AES way.
I aggree with with you but I rather vote to introduce a new evnt_multi AES system call for that. Applications that are aware can use the new system call and there is no compatibility problem. Internally XaAES only need to wrap old evnt_multi to the new one. The new evnt_multi can also be designed a bit better in this case :-) 

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