From mint-bounce@lists.fishpool.fi Fri Oct 29 17:43:03 2004 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Date: Fri, 29 Oct 2004 17:41:25 +0200 (CEST) From: Frank Naumann X-X-Sender: fnaumann@muecke.local To: mint@fishpool.com Subject: Re: [MiNT] Fpoll() in GEM programs In-Reply-To: <20041029145241.12056.qmail@mailcz.in.systinet.com> Message-ID: <20041029172335.D20936@muecke.local> 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> <20041029145241.12056.qmail@mailcz.in.systinet.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scan-Signature: 97c589d86249e00b2b3dfe1152414e09 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: fnaumann@cs.uni-magdeburg.de 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=-1.0 tagged_above=-50.5 required=3.8 tests=BAYES_00 X-Spam-Level: Hello! > 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. But it's a problem that you propose something without thinking about all the consequences your proposal implies. It's not as trivial as it looks like from your point of view as AES program. There are a lot of side effects that need to be evaluated too (but if I ask here I just got the answer this is implementation detail, nothing important). > So the question for you is "Is there any way to get it like this?". With or without the side effects you don't want to discuss? > 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. Btw. where is the big advantage here now against an enhanced evnt_multi except that you need an additional system call to process AES events? > 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). Yeah, I love such answers. Regards, Frank -- ATARI FALCON 060 // MILAN 060 ----------------------------------------- http://www.cs.uni-magdeburg.de/~fnaumann/ e-Mail: fnaumann@freemint.de