From mint-bounce@lists.fishpool.fi Wed Oct 27 19:48:26 2004 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <417FE0B2.5010403@utbm.fr> Date: Wed, 27 Oct 2004 19:53:54 +0200 From: Olivier Landemarre User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Standa Opichal Cc: mint@fishpool.com Subject: Re: [MiNT] Fpoll() in GEM programs References: <417CD550.80306@atari.org> <417D9690.4060707@atari.org> <20041027172635.1489.qmail@mailcz.in.systinet.com> In-Reply-To: <20041027172635.1489.qmail@mailcz.in.systinet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: olivier.landemarre@utbm.fr 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: Standa Opichal wrote: > Hi! > >> Since we wanna add fselect()/fpoll() functionality via evnt_multi() >> perhaps an extended version of evnt_mult() is in place? > > > I think I find a better way then the one with extending AES... We can > create AES event_multi pipe (e.g. U:\pipe\$PID\event_multi) for each > GEM application in XaAES so that the only thing the application needs > to use is the Fpoll() to detect activity. > Piece of pseudo code to explain: > # main application loop > while(1) { > # wait for an event on several filedescriptors > Fpoll( /pipe/$PID/event_multi, /pipe/fsel, /pipe/xxx ); > # take an action according to the type of event > switch ( which_pipe ) { > case event_multi: > use event_multi() as in every other GEM app. > case fsel: > handle pipe comunication > case xxx: > ... > } > } > This seems to me a better way to get the GEM applications capable of > using UNIX sockets and other things without being forced to create > separate child processes mainly because it would be backward > compatible in terms of AES API. > Opinions? If I understand it's only to know if there is already a message in queue? Because I not see any other type of event able to be manage like this (how AES can know for example that you wan't to wait for a click button?). So if it's for this, there is already a way to do this since AES 4.0, just replace evnt_message() by appl_read(-1,16,message) it will return immediatly with 0 if no message is waiting. Notice you can do an event_multi with timer 0 (not recommand), but it will be probably slower, but for this XAAES is very fast Olivier > > >