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.