Re: [MiNT] Fpoll() in GEM programs

["Arnaud BERCEGEAY" <arnaud.bercegeay@free.fr>]

Hello,

> Until know you only speak very vague about the descriptors. Please be  
> concrete about who create the descriptors, who own the descriptors, how  
> they are visible, how is access control organized, who manage the  
> resources and so on.

Well... i cannot precise a lot of thing because most of file descriptor  
internals are very obscure to me, but i can be more precise in my proposal.

The general idea is to provide "an event on a file descriptor" when  
something is ready to be read by evnt_multi.

let's talk about requierements:
the application shall be able to detect this "event on a file descriptor"  
by using Fselect (or Fpoll...)

That's all. The application shall not read things from this file  
descriptor, the application shall not write things to this file  
descriptor. The application shall only have read access to this event.

About the creator and the owner of the file descriptor... as the  
application doesnt' use it, i think AES can do all the job (creation, do  
something to trigger the event, do something to reset the evnt when  
evnt_xxx() is invoked, destruction), but  as the application should read  
event that occurs on this file descriptor, the owner should be the process  
of application (i'm talking about the obscure part for me... please  
correct me).

For ease of implementation, we can add a constraint like : only one file  
descriptor per AES application. This is a global data in the AES for this  
application, so that AES can manage it.

Now, if we talk about the kind of file descriptor, the kind of event on  
the fd to wait for (read? exception?)... i really don't know, but that  
should remain internal to the AES in my opinion (for example AES writes a  
character in the fd when something is ready to be read in evnt_multi(),  
and empty the content of the fd when evnt_xxx() is called, then  
application wait for "file ready for reading" event on the fd).

If we want to protect the fd against evil application (prevent the  
application to read/write stuff from/to the file descriptor, maybe it's  
not possible, but really that's not a hudge issue IMO.

best regards,
Arnaud.