home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / hensa / misc / tornado / easy001 / 5 < prev    next >
Text File  |  1995-07-23  |  3KB  |  53 lines
  1. Crash protection
  2. -=-=-=-=-=-=-=-=
  3.  
  4. From the moment a tornado app declares itself to be that, either by being
  5. started as a subtask or by calling Tornado_Initialise, it comes under the
  6. protective wing of Tornado. From now on, there are very few ways tornado apps
  7. can lock up the machine.
  8.  
  9. Tornado monitors all filing system operations done by the task, and closes
  10. any files that are still open when an app terminates (unless vetoed by a
  11. service call or wimp service message broadcast). Also, it installs handlers
  12. to deal with Undefined instructions, Prefetch aborts, Data aborts, Address
  13. exceptions, Branch through zeros, CAO exiting errors, normal errors and when
  14. OS_Exit is called.
  15.    For Undefined instructions, Prefetch aborts, Data aborts, Address
  16. exceptions, Branch through zeros and CAO exiting errors, polling is halted
  17. on that task and a window is displayed telling the user that this fatal error
  18. has occurred, and what should be done about it. The user also has the option
  19. to save out any files currently loaded into that app, or to save them into a
  20. temporary space and restart the app, which will then reload in those files,
  21. or to ignore the error and continue (in which case you'll get the usual error
  22. box, and lose your files).
  23.    For normal errors, usually the task has its own error handler installed to
  24. deal with these errors, but it may request that this operation be automated.
  25. Again, the format of the error box is much the same, in which normal
  26. operation is normally halted of that app, but multitasking continues
  27. unabated.
  28.    For OS_Exit being called before Tornado_Closedown, tornado cleans up,
  29. again by asking the user about any unsaved files etc. etc.
  30.  
  31. For tasks being preempted, eg; subtasks, if the task goes into a never-ending
  32. loop, and if the messages waiting for it exceeds a certain value, a message
  33. pops up to the user indicating that it is most likely that the task has
  34. crashed, and does the user wish to terminate the task.
  35.    For tasks not being preempted ie; polling normally; should they suddenly
  36. stop polling without indicating they are about to do so by sending a message
  37. (NOTE: this hasn't been finalised yet) via Wimp_SendMessage to the main
  38. Tornado task, and it agreeing that it is okay, failure to poll after 1 second
  39. since gaining control will cause control to be forcibly removed and the user
  40. asked if he/she wants the task terminated. Note however that Tornado may
  41. start preemption on that task requesting that it may begin single-tasking
  42. processing without its knowledge (at user discretion), and store all the
  43. polling codes normally returned and then pass those codes through
  44. Tornado_Poll back to the app when it indicates that it has finished
  45. processing by sending another wimp message.
  46.  
  47. This leaves only a few ways left of locking up the machine, ie; the ones
  48. which would usually cause a full reset to get out of them. Due to the
  49. structure of RISC-OS, it's _very_ difficult to get around these, but I'm sure
  50. you'll agree that the proposals above with certainly help no end.
  51.  
  52. Hmm - did I leave anything out? Don't think so ...
  53.