From mint-bounce@lists.fishpool.fi Wed Oct 12 08:38:42 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <434CAFD1.9030303@utbm.fr> Date: Wed, 12 Oct 2005 08:40:17 +0200 From: Olivier Landemarre User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MiNT-Liste Subject: Re: [MiNT] Calling gemdos function from Interruption References: <001778d5.01c15c7e17a8@smtp.freeola.net> <1128976918.434ad216e758c@webmail2.utbm.fr> <141829466.20051011124012@der-ingo.de> <1129037507.10951.15.camel@taro.coolrunningconcepts.com> <1129054159.434bffcf57b82@webmail2.utbm.fr> <434C05E8.709080 In-Reply-To: <434C05E8.7090804@highlandsun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: olivier.landemarre@utbm.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.6 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: Howard Chu wrote: > olivier.landemarre@utbm.fr wrote: > >> Selon Evan Langlois : >> >>> 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. > > > 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 > gemlib source. 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 Olivier