[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Fpoll() in GEM programs
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