Re: [MiNT] [XAAES] Does not generate MU_TIMER events when asked

[Odd Skancke <ozk@atari.org>]

tor, 07,.07.2005 kl. 16.18 +0200, skrev Patrice Mandin:
> Le Thu, 07 Jul 2005 16:07:13 +0200
> "Arnaud BERCEGEAY" <arnaud.bercegeay@free.fr> a écrit:
> 
> > >  I dont like the 'other AES' method, and am fishing for suggestions
> > > here.
> > 
> > 100% agree here :)

 Thinking about this a bit more I'm not sure what I think. There are
advantages not having evnt_multi() 'split' or 'stop' a timeout. So that
when the TIMER event happens you know the time originally passed to
evnt_mulit() have passed. This is useful when you need a long delay for
something, and dont want to be unable to service other events in the
meantime. However, this way of handling things is not logical looking at
the current MU_TIMER implementation, because this means you cannot
change your mind until the MU_TIMER triggers. But in order to keep the
existing things as compatible as possible, I have changed it to be like
the above. However, calling evnt_multi() or evnt_timer() without
MU_TIMER bit set will cancel any pending timeout.


 Then there's the situations where one wants to stay in evnt_multi() for
a specified amount of time, and not be dependant of how much is
remaining of an old MU_TIMER setting. Here one wants to be sure that if
the timer value passed is 100ms, it will take at least 100ms for
evnt_multi() to return. If other events happen before this timeout, the
next evnt_multi() whould reset the timeout to make sure at least 100ms
pass before return (when no other events happens, ofcourse)

 Now. How do we solve this? Should we spend a bit in event flags word
for this? If so, I have a suggestion;

 Add MU_FSELECT, and use that timeout to behave like normal. That is, if
the parameters to the rest of the fselect() is empty, only use the
timeout. This would solve two problems at once. Ideas?


> > 
> > I like very much the way XaAES manages MU_TIMER events, and i don't
> > like the way 'other AES' do it.
> > 
> > Just my opinion ;)

 Thanks :-)

> 
> This is fixed on my side, I was using MU_M1 and MU_M2 at the same time,
> preventing any MU_TIMER from triggering.

 Yes .. but now it is triggering because of the change...


Best Regards
Odd Skancke