[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Calling gemdos function from Interruption
Howard Chu wrote:
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
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
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
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
gemdos. So yes it's possible, just need to call appl_write() from
handler, but warning in managing it, the thread receiving the signal
it's own AES identifier (have done an appl_init(), and have a
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
send to itself a message, in this case it can use it's own AES
don't need appl_init() for this.
The only way I ever found to do this was to use two processes/threads.
One process waits in evnt_multi(), the other process waits in select()
on a pipe. When a signal handler fires, it writes a byte to the pipe.
The process selecting on the pipe wakes up and sends an AES message to
the other process. When the program wants to shutdown, the AES process
writes a byte to the pipe, and the select listener wakes up and exits.
It is not safe to call any AES functions from a signal handler.
Yes possible on NAES as said Ingo, I not see for my own aes any trouble
with this to call appl_write() but I have to do attention in futur,
because I plane to change this part.
For actual hardware interrupt processing, obviously the best way is to
write a device driver that shields user-level code from this level.
But I added the PsigIntr call to MiNT specifically to allow a user
program to direct hardware interrupts to a user's signal handler.
When I was working on Digital Storefront years ago, the standard
gemlib wasn't appropriate for the task; it used a single table of
parameters for all its AES/VDI calls. I had to rewrite most of the
entry points to allow a context pointer to be used instead, so that my
two threads could call the AES without tripping over each other. I
don't remember if my patches ever got incorporated back into the main
Oh yes you have totaly true, for VDI with new gemlib, there is no
problem for now, for AES call you should use MT_aes_function() with your
own mt_global, the thread should have done a personal mt_appl_init()
and not use the global program. This is in new gemlib too. Perhaps it is
possible not create a thread, but there is possible confusing for AESs
in client research (should work in MyAeS). Using standard aes function
is totaly forbidden