Hello,
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 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'tknow 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).
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 remains unanswered.
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 read.
OR(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.
best regards, Arnaud.