Re: [MiNT] Fpoll() in GEM programs

[Frank Naumann <fnaumann@boerde.de>]

Hello!

> 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.

And how is the filedescriptor visible to the application? What should 
happen if the application try to close it? How does the AES detect that 
the application want to use the filedescriptor, e.g. a pipe will block if 
the pipe buffer is full.

> From my point of view such design is much more worse than a new AES system 
call. The point is that you modify/blur the clean semantic of a 
filedescriptor, e.g. it's not a filedescriptor in the way UNIX define 
them. It's something magic that automatically exist, but it's not readable 
or writeable.


Regards,
Frank

--
ATARI FALCON 060 // MILAN 060
-----------------------------------------
e-Mail: fnaumann@freemint.de