[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Fpoll() in GEM programs
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 ...
Yeah! replace xevnt_multi() by evnt_multi() or any other name you prefer.
It's an existing AES call and a new AES call but it's an AES call. Same
for MU_SELECT: you can rename to MU_MINT_KERN_STUFF if you prefer.
With solution 3.2, AES will have to manage mechanism which are out of
of the AES (a process creates a socket, and this process asks the AES
it when something happen on this socket... a socket on which the AES
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).
I don't agree. You speak of "magics", and you're right if we use OOB, but
there's others ways to use file descriptors.
I think we completly misunderstood each others, and the main question
The main question is how to merge a Fselect() and evnt_multi() in one call
And i see only 2 ways (what i called solutions 3.1 and 3.2).
(3.1) We choose Fselect() as main loop, and so AES shall use
filedescriptor to inform the application that AES events are ready to be
(3.2) We can extend the evnt_multi() AES call (or create another AES
function that will replace evnt_multi, that doesn't matter) so that it
internally checks events on various file descriptors as well (using
Fselect/Fpoll i think).
What i think: solution 3.2 seems much more easier to make, and not only
for freemint/xaaes layers, but also for upper layers (gemlib, high GEM
lib...), and solution 3.2 is an answer to our need... But the reason "its
much more easier to do 3.2" is not a good reason. It's a good argument to
choose between 3.1 and 3.2 if both 3.1 and 3.2 are acceptable, but for now
we haven't state that 3.2 is acceptable (read below).
By choosing solution 3.2, we state that evnt_multi (or any other AES new
call that will replace it) IS the only call of the main loop of AES
application, and so, this function (let's call it evnt_multi) shall manage
all the stuff that any application may manage. Fselect() is our first
step, but maybe others may follow... And to be consistent, if evnt_multi
is able to return on Fselect event, then we shall add evnt_fselect(),
which seems stupid... so it's stupid to be consistant with this extension,
and that simply because we ask AES to manage fd that are out of the scope
of the AES.
If you think it's acceptable for the AES to manage stuff that are foreign
to the AES, please say it. If we agree on that point then solution 3.2 is
the far better solution.
For now, i only heard two opinions on this question, which are that "maybe
3.2 is not good".
BTW, as Xavier and Olivier pointed out, we can still create threads, and
this works for MagiC 6 too.