Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!unido!fauern!faui44!mlelstv
From: mlelstv@faui44.informatik.uni-erlangen.de (Michael van Elst )
Newsgroups: comp.sys.amiga
Subject: Re: Need info on exceptions
Message-ID: <613@faui44.informatik.uni-erlangen.de>
Date: 29 Aug 88 08:56:00 GMT
References: <3793@louie.udel.EDU>
Reply-To: mlelstv@faui44.UUCP (Michael van Elst)
Organization: CSD., University of Erlangen, W - Germany
Lines: 66

In article <3793@louie.udel.EDU> iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) writes:
>[In "Re: Need info on exceptions", "Morgan W. Jones" said:]
>>
>> In article <1754@munsell.UUCP> jdj@munsell.UUCP (Joel Jennings) writes:
>> >I am looking for a way to cause my program to take an exception periodically
>> >so that it can write out intermediate results of a long calculation* (see
>>
>> ... asks about software interrupts from the timer.device ...
>>
>Unfortunately it can't.  "To avoid serious problems, the interrupt
>routine must not use any of the memory allocation or deallocation
>functions"--RKM.  That's apparently because critical system code
>is surrounded by Forbid(), but not Disable().
>
>That doesn't seem to leave much that interrupts can do.  Once again,
>we're stuck with polling (and this on a multitasking OS).

Hello,

I don't think that you have to poll for this. There are two approaches
to this problem.

If your program is designed as an event loop (i.e. a loop Wait()ing
for messages and then working on each of them) you can easily send a
request to the timer.device to wake you up. When the timer replies your
request you can write out your intermediate results and post another
request to the timer.
Thereis a problem if you have to Wait() at another point in your program
(likewise a DOS call, that Wait()s internally for IO to complete).
You MUST disable any verify IDCMP messages for intuition is locked until
you reply. If then a requester wants to apear ("Please insert...")
you get a deadlock situation.
You might disable other event sources (i.e. menus) if handling an event
lasts for a longer time. Otherwise input events might be allocated
at your message port and might not be freed until your program ends.

If your program cannot be designed as an event loop (in this case it
seems to be so for you want to calculate something) you may spawn
another process that deals with the DOS and that is woken up by
the timer.device. The problem there is to get a real 'Process' because
you have to call DOS routines, a simple 'Task' cannot do this.
The only legal way to create a process is to call the DOS function
CreateProc but it uses a structure called SegList. Therefore
you have to LoadSeg() your updating process and to communicate with it
to get pointers to your first process' memory. Or you have to construct
your own SegList but I haven't found a method to do this from C.
(I think Lattice C can do it but I am not sure)
A simpler method to get around the need for a process is to construct
your main program as an event loop and spawning a 'Task' to do
your calculations. To display your calculations (if it is for example
a Mandelbrot set or a raytracing picture) you then can send messages
to your main process to indicate that a part of the calculation can
be used.
The task model is sufficient for most applications for you hardly need
two or more processes twiddling with DOS. And even this could be done
by a single process using asynchronous IO (i.e. sending DOS packets
instead of calling DOS functions).

Enough said.


				Michael van Elst

E-mail: UUCP: ...seismo!unido!fauern!faui44!mlelstv
E-mail: UUCP: ...uunet!unido!fauern!faui44!mlelstv	<- when seismo ceases
							   operation