From mint-bounce@lists.fishpool.fi Tue Oct 11 15:35:50 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] Calling gemdos function from Interruption From: Evan Langlois To: Ingo Schmidt Cc: MiNT-Liste In-Reply-To: <141829466.20051011124012@der-ingo.de> References: <001778d5.01c15c7e17a8@smtp.freeola.net> <1128976918.434ad216e758c@webmail2.utbm.fr> <141829466.20051011124012@der-ingo.de> Content-Type: text/plain Date: Tue, 11 Oct 2005 08:31:47 -0500 Message-Id: <1129037507.10951.15.camel@taro.coolrunningconcepts.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - CoolRunningConcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Evan@CoolRunningConcepts.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=1.9 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, RCVD_IN_SORBS X-Spam-Level: * 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!). -- Evan