[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [MiNT] Calling GEM from within a signal handler
- To: MiNT Mailing List <mint@atari.archive.umich.edu>
- Subject: RE: [MiNT] Calling GEM from within a signal handler
- From: Mario Becroft <mb@tos.pl.net>
- Date: Fri, 16 Apr 1999 09:23:37 +1200
- >received: from localhost by tos.pl.net with smtp (Smail3.1.29.5 #1) id m10XiN0-0001FnC; Thu, 15 Apr 99 21:23 NZST
- In-reply-to: <000e01be8711$7478f330$cf00a8c0@nbreschke>
- Sender: owner-mint@fishpool.com
On Thu, 15 Apr 1999, privat wrote:
> Let the signal handler set a flag and poll that with AES timer events.
> Alternatively, let the signal handler create a new thread using Pexec 104,
> and then that thread can send an AES message to the original thread.
Let me explain a little of what I am trying to achieve. I have a program
which will do some lengthy processing, but I want the user interface to
respond even while the lengthy process is taking place.
The idea was for the program to invoke a separate thread when it
loads which handles the GEM user interface, while the original program can
do lengthy processing. But obviously I need some way for the two to
communicate.
The lengthy process needs to be able to communicate quickly with the user
interface, and I think polling with the GEM timer event would not be
practical.
I think that the best option is to have the lengthy process also be a GEM
application, this way it can communicate with the user interface via GEM
messages. I wanted to avoid this, if possible, since it would mean that
the program is listed twice in the list of current GEM apps, and also if
users selected the lengthy processing app instead of the user interface
app they would not be able to interact with the program, it appears.
Given the above, the possibility of creating a new thread to send a GEM
message each time a signal is received appears even more impractical,
since each time the thread is created it would have to use appl_init and
appl_exit, and the user might find this application that continually comes
and goes disconcerting. We could also have a thread continually running
specifically for receiving signals and turning them into GEM messages, but
again this is no better than the above solution.
After all that, what I am trying to do amounts to interrupting a GEM
application from a non-GEM program. Is there an alternative way of
achieving what I want to do?
--
+-----------------------------------------------------------------------+
| Mario Becroft * Tariland, New Zealand Atari User Group |
| mb@tos.pl.net * Atari Hardware Developments |
| http://pl.net/~mario/ * Atari Serial Mouse Interface |
+-----------------------------------------------------------------------+