From mint-bounce@lists.fishpool.fi Sun Oct 31 23:39:57 2004 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Date: Sun, 31 Oct 2004 23:38:27 +0100 (CET) From: Frank Naumann To: mint@fishpool.com Subject: Re: [MiNT] Fpoll() in GEM programs In-Reply-To: <1099125907.4183549370b3e@imp4-q.free.fr> Message-ID: 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 <1099125907.4183549370b3e@imp4-q.free.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: fnaumann@boerde.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=-0.7 tagged_above=-50.5 required=3.8 tests=AWL, BAYES_00 X-Spam-Level: Hello! > Yes. This is what i have in mind, and OOB seems to be a mechanism that can help > for that purpose. Using the error exception condition for regular events is the worst idea I heard until now :-) > Solution 3.1 allows the programmer to use the more suitable function the manage > socket > stuff. He can use select(), pselect(), poll(), or gemdos Fselect()... Just for clarification, it's all the same. select/pselect/poll are the UNIX defined interfaces in MiNTLib, Fselect/Fpoll are the system call interfaces (Fpoll is a replacement for Fselect that allow getting rid of the 32 filedescriptor limit). > With solution 3.2, the programmer HAVE TO use gemdos Fselect() (thru > xevnt_multi(MU_SELECT)), he has no choice. Hmm, did we already defined how it looks like? I thought we discuss about design here ... > With solution 3.1, AES shall inform the application that something is ready to > be read by evnt_multi(), and AES shall do it thru a fd event because the main > loop() only waits for fd events (this is the "how to do this" we discussed on > the ML). > > With solution 3.2, AES will have to manage mechanism which are out of the scope > of the AES (a process creates a socket, and this process asks the AES to inform > it when something happen on this socket... a socket on which the AES doesn't > know anything). I'm sorry that I must tell you that with 3.1 the problem is even worse. The AES need to manage a filedescriptor and need todo magics to push it back into the process filedescriptor table and the AES need to define semantics for this special filedescriptor (what happen on fork, what happen on exec and so on). This is in my eyes much more worse than to call the kernel through a defined interfaces if there are events available for the specified filedescriptors. > I prefer solution 3.1 because it's more generic (we let freedom for the main > loop : select/pselect...), As already mentioned, there is no difference. Regards, Frank -- ATARI FALCON 060 // MILAN 060 ----------------------------------------- e-Mail: fnaumann@freemint.de