Re: [MiNT] Fpoll() in GEM programs

[arnaud.bercegeay@free.fr]

Hello!

> > The AES writes stuff to itself, and read stuff
> > from itself, using OOB data; i don't see any magical thing here.
>
> I don't understand. Until know you said the AES inform the process about
> new AES events through a file descriptor.

Yes. This is what i have in mind, and OOB seems to be a mechanism that can help
for that purpose.

BTW, I think we have mix up some differents proposals... and then we lost the
original subject.

Let's go back to the main subject, and moreover on the REAL need for this
extension.

There are AES application, where evnt_multi() is the main loop, which allow the
application to give the hand to others processes, until one of the expected AES
event occurs.

There are non-AES application that mainly manage files (socket...). For these
programs, the main loop is select(), or pselect(), or poll(), or Fselect()...
anything that allow the process to give the hand to other processes until one of
the
expected event in one of the file descriptor appears.

The question is: what should be the main loop() if an AES application have to
manage messages through sockets (for example).

If this is not the main question for you, please tell me now, stop reading this
mail and explain what's the real purpose of the extension in your opinion.


SOLUTION 1 :

Without modification of the AES, we set the 2 loops in a main loop:

while(1) {
         evnt_multi(); /* with a short timer value */
         if (evnt) do_aes_stuff();

         select(); /* with a short timeout */
         if (evnt) do_fd_stuff();
}


SOLUTION 2 :

Create a thread for select() stuff. The thread will have select() as main loop,
and the main application will have evnt_multi() as main loop... but a dialog
between the main application and the thread is needed (otherwise, the main
application and the thread may be splitted in 2 independant programs).
So, we just have to create a pipe (?) between the main process and
the thread... and then we have to add a select() loop in the main application
to manage this pipe. We're back at the starting point.


SOLUTION 3 :

merge the two loops, so that the main call of the loop only returns when either
an AES event has occured, or an expected event on a fd has occured.
This solution is the less time consuming, and the most reactive.

There are two philosophies:


SOLUTION 3.1

the program first aim is to manage socket messages, and so the main loop is
select(). AES should inform the application that and AES event has occured and
is ready for reading by triggering something that made select() to return. The
1st idea is a file descriptor dedicated for that purpose.


SOLUTION 3.2

the program is mainly an AES application, the main loop is evnt_multi and AES
has to return when one of the event expected by the program appears, even if
this event
is out of the AES scope... So evnt_multi should be extended in order to be
able to detect all kind of event that any application may wait for (event on
fileselector, semaphore free-ed...).


SO WHAT ?

i hope that we all agree that solution 3 is a good solution.

About the choice between 3.1 and 3.2 :

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()...
With solution 3.2, the programmer HAVE TO use gemdos Fselect() (thru
xevnt_multi(MU_SELECT)), he has no choice.

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 prefer solution 3.1 because it's more generic (we let freedom for the main
loop : select/pselect...), and because we don't ask the AES to manage mechanism
which are independant and out of the scope of the AES.

BTW, it's just a "small" preference. For me, solution 3.2 is not a bad solution.

Now, if i understand correctly, there are no mechanism in freemint that allow
the AES to create a fd and trigger an event on this fd; if so then solution 3.1
is a no-way solution and the only solution remaining is 3.2

If both solution 3.1 and 3.2 could be easily done, i'd like to know what you
prefer between 3.1 and 3.2... and if it's only a small preference like it is for
me (i'll be very happy with either 3.1 or 3.2).

best regards,
Arnaud.