Re: [MiNT] Calling gemdos function from Interruption

["olivier.landemarre@utbm.fr" <Olivier.Landemarre@utbm.fr>]

Selon Evan Langlois <Evan@CoolRunningConcepts.com>:

> On Tue, 2005-10-11 at 12:40 +0200, Ingo Schmidt wrote:
>
> > I can call GEMDOS calls within a signal handler. And in XaAES I can
> > even make AES calls from within a signal handler.
> >
> > But a signal handler is context dependant. The OS knows to which
> > process a signal handler belongs.
>
> My first reaction was "why?", since, in Unix, I'm used to simply setting
> a flag or something in a signal handler, and then handling the signal
> from the process's main event loop, keeping the signal handler as small
> as possible.
>
> However, with the Atari, most event loops are simply just a call to
> evnt_multi(), which doesn't handle file handle events.  Being able to
> call GEMDOS within the signal handler could possibly be quite useful as
> you could have a background thread handling file/pipe/network IO and
> simply send a signal to the parent AES process to tell it to update its
> display.
>
> If evnt_multi was the last OS call made when a signal handler fires,
> does evnt_multi() return with some error code to say it was interrupted
> by a signal (making it possible to use the "set a flag and handle it in
> the main event loop method) or does the evnt_multi() continue to wait
> for AES events (meaning you'd have to handle the signal completely
> within the signal handler, and being able to call GEMDOS and AES would
> be incredibly useful!).


For AES this should be possible for any multitask AES, I think if it's from a
signal, if it's from hardware interrupt, it's possible except probably for AES
in kernel module, because if I have understand this will the same problem as
gemdos. So yes it's possible, just need to call appl_write() from your signal
handler, but warning in managing it, the thread receiving the signal should have
it's own AES identifier (have done an appl_init(), and have a diffrent global
buffer from application to send message), because it can have problems in futur
AES systems. So probably you can already do this. Perhaps more simple, I think
the application can receive signal when it is sleeping in event_multi(), then
send to itself a message, in this case it can use it's own AES identifier, so
don't need appl_init() for this.


Olivier