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

Re: [MiNT] Fpoll() in GEM programs



Hello,

And how is the filedescriptor visible to the application?

So the file descriptor is owned by the application.

Is it possible for the AES to create a file descriptor, and set the current process id as the owner of this file descriptor ?

What should happen if the application try to close it?

What's happen if you fopen() a file (FILE*), and close its file descriptor (close()), and then try to read stuff in this FILE* ? What's happen if an application Fcreate() a file, then Fclose() it, and then Fwrite() data to the fd returned by Fcreate() ? What's happen if application Mfree() data in aes_global[5,6] (resource), and then invoke rsrc_gaddr() ?

The fd shall be considered as a resource of the application (like aes_global[] array is), and the application is reponsive of its integrity. The application shall not do stuff that are not allowed, but this application can do nasty things if it want to block or crash itself.

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.

I never talked about pipe. I only talked about the generic "file descriptor" term, because it cover lot of things.

Ok... i'll once more try to argument on a subject i don't know very well... BTW, if i correctly understand, we cannot create a file descriptor. We can create a file and the function returns a filedescriptor. We can create a pipe and the function returns a fd. We can create a socket and the function returns a file descriptor... a "file description" is a generic handle that may hide a lot of very different things, and i'm not sure that pipe is the good type for our need.

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.

There's nothing magic. We can read/write stuff to this file descriptor (if needed), but only AES functions has to do it.

I can point out a direction of implementation (we are talking about implementation now), which is the parameter exceptfds of select().

Here is what i read from http://www.netadmintools.com/html/2select_tut.man.html

"
exceptfds
This set is watched for exceptions or errors on any of the file descriptors. However, that is actually just a rumor. How you use exceptfds is to watch for Out of Bounds (OOB) data. OOB data is data sent on a socket using the MSG_OOB flag, and hence exceptfds only really applies to sockets(...)
"

This feature may be used, no ? The AES writes stuff to itself, and read stuff from itself, using OOB data; i don't see any magical thing here.

best regards,
Arnaud.