From mint-bounce@lists.fishpool.fi Tue Oct 11 20:36:40 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <434C05E8.7090804@highlandsun.com> Date: Tue, 11 Oct 2005 11:35:20 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050925 SeaMonkey/1.1a MIME-Version: 1.0 To: "olivier.landemarre@utbm.fr" Cc: 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> In-Reply-To: <1129054159.434bffcf57b82@webmail2.utbm.fr> 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: hyc@highlandsun.com 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, TO_ADDRESS_EQ_REAL X-Spam-Level: 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. 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. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/