jdj@munsell.UUCP (Joel Jennings) (09/01/88)
[Offering to the great line eating god - may it serve you well...] >"I am looking for a way to cause my program to take an exception so that > it can write out the intermediate results of a long calculation..." Thanks to everyone who mailed/posted answers to my inquiry about checkpointing a processing task. The current scorecard reads as follows: 1) I can poll for some external signal (CheckAbort() seemes to be best) and write out results when the signal arrives. Generate the signal with another CLI spawned task. [I knew this. This method is not what I want to do, since my "loop" executes a quingigillion* times for each problem.] 2) Determine algorithmically (as in "count the number of iterations") the appropriate time in the loop to put checkpoint code. [Again, unsuitable unless absolutely necessary. See answer to #1.] 3) I cannot use software or hardware interrupts, since I won't be able to do anything useful during an interrupt. [I agree - whoever wrote this section of the OS must have failed or forgotten their intro to OS course.] 4) I can use an external process to checkpoint the calculation process by having the calculation process send the checkpoint process the address of the calculation data. Generating an external process, however, is cumbersome. [A tolerable solution, but messy! Having shared data is very poor style, and leads to bugs. May be necessary in this case, though. Thanks, Matt!] [This particular problem does not need synchronization between the two tasks. In the general case, semaphores (or something) would be needed, and solution #1 would end up being faster.] [Actually, I would have generated the checkpoint process from the CLI and have the two processes communicate via a public message port. This seems a lot cleaner than trying to generate one process from within another. Or am I missing something?] 5) I can setup an exception handler for the timer message: when the message is delivered, my process will be interrupted and forced to call the specofied routine. [Just what I was looking for (my thanks go to Bill Kinnersly!). Howcome this isn't mentioned in the documentation?] *Quingigillion: The number of miles from the electric monk to Salt Lake City, Utah. -- Joel Jennings | Wampeters, foma, and granfaloons. |
jesup@cbmvax.UUCP (Randell Jesup) (09/01/88)
In article <1757@munsell.UUCP> jdj@munsell.UUCP (Joel Jennings) writes: > 3) I cannot use software or hardware interrupts, since I won't be able > to do anything useful during an interrupt. > > [I agree - whoever wrote this section of the OS must have failed > or forgotten their intro to OS course.] Actually no. This is not at all unusual for OS interrupt handlers (as opposed to unix signal handlers, which are NOT even close to interrupts). However, it is easy to have an interrupt signal another task to wake up, or to copy info into a preallocated area of memory, then signal a task to wake up and write it out. > [Actually, I would have generated the checkpoint process from the > CLI and have the two processes communicate via a public message > port. This seems a lot cleaner than trying to generate one > process from within another. Or am I missing something?] Sure, it'll work. > 5) I can setup an exception handler for the timer message: when the > message is delivered, my process will be interrupted and forced > to call the specofied routine. > > [Just what I was looking for (my thanks go to Bill Kinnersly!). > Howcome this isn't mentioned in the documentation?] Because I believe (not verified!) that that is not safe. In particular, you could get an exception while in an OS critical section, so doing many things may not be safe (similar to interrupts). If you are sure you're safe, this could be done. The reason it isn't stressed is that it was designed for such uses, then people realized that given the way the OS was designed, it wasn't safe to use in the way Unix signal handlers are used. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup