From mint-bounce@lists.fishpool.fi Fri Oct 29 16:54:37 2004 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <20041029145241.12056.qmail@mailcz.in.systinet.com> References: <417CD550.80306@atari.org> <20041027172635.1489.qmail@mailcz.in.systinet.com> <417FE0B2.5010403@utbm.fr> <200410280115.29861.h.robbers@chello.nl> <20041028084227.K3028@muecke.local> <200410 opsgmjjcav8yw5lr@localhost.localdomain> <20041029123519.O20936@muecke.local> In-Reply-To: <20041029123519.O20936@muecke.local> From: Standa Opichal To: mint@fishpool.com Subject: Re: [MiNT] Fpoll() in GEM programs Date: Fri, 29 Oct 2004 16:52:41 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: opichals@seznam.cz Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.6 tagged_above=-50.5 required=3.8 tests=AWL, BAYES_00 X-Spam-Level: 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