home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / hensa / misc / tornado / easy001 / 1 next >
Text File  |  1995-07-23  |  5KB  |  89 lines
  1. Continous polling, I/O, OLE and hotlinking
  2. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  3.  
  4. As you may have heard, one of Tornado's main attributes is that of continual
  5. polling, or multitasking. Tornado does this by providing *-commands to load
  6. in code while polling. A background operation hourglass appears during this.
  7. Also, any i/o operations are done by Tornado, including serial, parallel,
  8. disc and inter-application i/o. Sometimes the i/o is done without the
  9. application's knowledge or involvement.
  10.    For a start, all low-level serial and parallel i/o is done using SWI
  11. Tornado_IOOp. Block gbpb taking more than 1cs to perform gets preempted,
  12. although the calling task can have the SWI return control instead so full
  13. application functionality is retained. I/o is done using the serial block
  14. drivers for the serial port, and with a specialised replaceable driver for
  15. the parallel port.
  16.    For more generalised use, i/o can be directed at tserial:, tparallel:,
  17. tprinter: and anything else that is added by third-party producers (eg;
  18. tethernet:). For the printer, tprinter: in fact is a FIFO buffer which takes
  19. in input and spits out output to the printer as fast as it can. I/o to
  20. tprinter: is preempted, unless the app wishes to retain full functionality.
  21. I/o to tserial: actually directs i/o to whatever is the currently selected
  22. serial driver(s) (can be different for different apps). Also, multiple apps
  23. can access the serial port at once, using a system like the input focus. The
  24. access requirements for eg; tethernet: have yet to be finalised.
  25.  
  26. That's general i/o. For more usual i/o like disc i/o, there's a different
  27. setup. For a start, applications do not know that a user has requested that a
  28. file be loaded into that application. Nor does an application know if the
  29. user saves the file out of it. Or if the user has OLEd a file currently
  30. loaded in. Or, for that matter, if the application has _any_ files loaded in
  31. at all.
  32.    How is this possible? Well, tornado applications are written to edit one
  33. file and one file only. Tornado handles the loading in of multiple files.
  34. Also, tornado applications do not /load/ in files, they rather replace an
  35. existing one. For example, loading in a tornado app and then loading a file
  36. into that actually replaces the blank file already loaded with the one being
  37. loaded in.
  38.    This means that the user OLEing a drawfile in a DTP frame simply does the
  39. following:
  40.    * User does OLE special-key & click.
  41.    * Tornado receives this, and checks the filetype of the file loaded into
  42. the frame in the DTP (i)
  43.    * Tornado checks the apps currently loaded in, and sees if any of them can
  44. load the file (ii), and if none are loaded in it checks to see if any
  45. suitable apps have been seen by the filer (iii)
  46.    * Tornado tells the receiving app to *replace* the currently loaded blank
  47. file with this file here, and passes it the address of the file loaded into
  48. the DTP package. It also tells the new-found editor where to open its editor
  49. window if appropriate eg; directly over the frame containing the original,
  50. scaled to the correct zoom factors etc. (iv)
  51.    * From now on, any modifications made to the shared file is accompanied
  52. with a message sent to all tasks with access to that file requesting that
  53. they redraw that file (v)
  54.  
  55.  (i) Tornado knows the filetype of every file loaded in because *it* does the
  56. loading in.
  57.  (ii) Tornado knows which filetypes each app loaded in can edit (without
  58. conversion) because the app declares them in its Tornado script file.
  59.  (iii) Tornado knows which filetypes each app on disc can edit because they
  60. are declared in the !Boot file of every app on disc. Tornado can build a
  61. 'map' of the disc by checking the disc for tornado apps, extracting what
  62. files they can load and compiling them into a list. When the Tornado filer is
  63. written, any changes made to the directory structure (ie; the user moves a
  64. file from here to there) will also update the list. Otherwise, or to save
  65. memory, Tornado can simply register any apps seen by the filer.
  66.  (iv) All files loaded into all tornado apps are stored in a central
  67. reservoir maintained by Tornado, and this lives in RMA. See the appropriate
  68. file about this.
  69.  (v) All files are redrawn by the Tornado renderers, which are available to
  70. all tornado apps. See the approriate file about this.
  71.  
  72. From the above, you can see how the user dragging a file from the filer to a
  73. tornado app would work, and dragging a file from another app to an app, and
  74. hotlinking a whole bunch of files together. It's even possible that a single
  75. file could be shared over a network eg; an alteration to a file on one
  76. station would affect all copies all over the network (and beyond). This would
  77. allow teacher's to monitor what any student is doing.
  78.  
  79. Note also, that all files loaded in and saved out go through tfs:. The file
  80. is loaded under multitasking into tfs:, and loaded into the app from there. A
  81. file is saved to tfs:, from where it is copied to disc under multitasking.
  82. This ensures constant multitasking.
  83.  
  84. I think I've covered most of how Tornado works concerning the above topics.
  85. Probably I've missed bits and pieces, but I couldn't be sure!
  86.  
  87. See also the file about subtasks, as subtasks play an immense part in
  88. implementing i/o.
  89.