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

Re: [MiNT] Fpoll() in GEM programs

Hi Frank, You are the guru for open()/read()/write()/select()/close()/socket()/pipe()/... operations. Our intention was not to outline all the implementation details for sure. We would just like to _propose_ a logical way to structure FreeMiNT (UNIX) AES application to not to be forced to use AES timers to be able to periodicaly check other input file descriptors in our application. The scenario now is like follows: 
loop {
   event_multi( MU_TIMER | MU_*, tens of arguments );
   if ( MU_* )
      ...
   else if ( MU_TIMER ) {
       select( input fd, 0 );
       if ( action )
          do_action();
   }
} Your proposal was something like this: 
loop {
  whatever_multi( MU_* | MU_SELECT [| MU_POLL][| MU_whatever we
                  find later], hundreds of arguments );
  if ( MU_* )
     ...
} The scenario to reach is (remember it is just a sketch): 
int aes_fd = get aes_fd somehow
loop {
   select( input_fds | aes_fd, 0 );
   if ( aes )
      event_multi_fast( 3 arguments );
   if ( action )
      do_action();
}
do some cleanup here So the question for you is "Is there any way to get it like this?". My _ideas_ (not implementation proposal - hell, I can't resist... does it really matter this wording we need to insist in this very first proposal stage???): On AES application request the AES can open a pipe and of course own it (whatever you can see that behind). It can restrict the permissions to be accessible only by a dedicated application I believe. The client should get (ot it would know based on a specified scheme) the name of the pipe to be able to use it. The pipe processing (to not to change the filedescriptor nature - like it was discussed before) would be completely normal. The AES would write there the output in a form of a return value of event_multi() call. The client would be woken up from select() and would read the value. It would also call the event_multi_*() to get the rest information it needs. AES should be able to detect whether the client read from the pipe or not and if it is not beeing read than it should rewrite the value (I think this will need some more implementation details, but I think they are not necessary at this moment). Best regards STanda
Frank Naumann writes:
Hello!
Is it possible for the AES to create a file descriptor, and set the current process id as the owner of this file descriptor ?
The kernel don't manage the resources in this way. Every process have it's own, private file descriptor table. But how does a process know what the AES provide this feature and how does the process know which is the right descriptor?
I never talked about pipe. I only talked about the generic "file descriptor" term, because it cover lot of things.
You know that there must be some code behind this file descriptor?
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.
So you need to introduce a new type.
There's nothing magic. We can read/write stuff to this file descriptor (if needed), but only AES functions has to do it.
There are lot of other things you are probably not aware yet. A file descriptor is more than just a read/write/select interacting resource: 
- A file descriptor is an elementar resource a process
  can create/modify/destroy
- A file descriptor is inherited by child processes
- A file descriptor is duplicateable
- A file descriptor is manipulable in various ways:
  - setting/getting attributes
  - modifying behaviour
- A file descriptor support fstat, fchown, fchmod and such things 
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 ?
So you want to use the error exception event to notify about regular AES events? Funny ...
The AES writes stuff to itself, and read stuff from itself, using OOB data; i don't see any magical thing here.
I don't understand. Until know you said the AES inform the process about new AES events through a file descriptor. 

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