home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 5 / DATAFILE_PDCD5.iso / utilities / t / tornado / Guide / 5 < prev    next >
Encoding:
Text File  |  1995-09-23  |  8.1 KB  |  140 lines
  1. Subtasks
  2. -=-=-=-=
  3.  
  4. Subtasks are an extremely powerful way of doing processing. They are
  5. TAOS-like in the way they can process in multiple threads. The benefits of
  6. TAOS are well known, and most of those benefits are available to tornado
  7. apps.
  8.    A tornado subtask is a normal tornado task, except that it is subject to a
  9. number of restrictions - they are only allowed to access memory within their
  10. own space and within the subtask heap, and can only communicate normally with
  11. their parent and their sibling subtasks. Generally speaking, they fill a
  12. buffer of processed data and pass this to their parent ie; they do their
  13. processing in sections.
  14.    The main advantage of using subtasks is that it allows a bit more of
  15. multithreading than usual with Basic. Due to Basic's structure, execution
  16. cannot occur at different parts of the program at the same time, so by using
  17. subtasks a Basic programmer can still have limited multithreading.
  18.    Another advantage is that with the arrival of multiprocessor Acorn's, the
  19. subtask can be executed on a seperate processor - and thus giving all the
  20. obvious advantages.
  21.    An example of this is a http fetcher. The parent html viewer, is asked to
  22. fetch http://www.acorn.co.uk for example. The parent, a tornado task, starts
  23. up one of its private subtasks stored within its directory (some subtasks are
  24. stored for public use ie; any tornado task can use them) which fetches http:
  25. links.
  26.    The subtask starts, and uses ttcpip: to send a http request. When
  27. receiving confirmation, it passes the message to its parent which displays
  28. the appropriate message. Then the html page arrives in packets, as is in
  29. tcpip's nature, and this is run through, picking out all the references to
  30. graphics/sound/movie. The graphics/movie are then sent for, by the subtask
  31. starting up siblings, which in fact are copies of itself. Each of these
  32. siblings reads in the graphic/first fram of the movie, checks what format it
  33. is, and then starts up the appropriate graphic convertor from the public
  34. convertor library, passing it the reference by which it can send its
  35. processed data to the parent app.
  36.    Ok, so now the picture looks like this:
  37.  
  38.                          Parent html (www) viewer
  39.                                     | Passes down http://www.acorn.co.uk
  40.                                     |
  41.                                     | Passes up html document
  42.                                http fetcher
  43.   Passes down http://www.         / | \         Passes down http://www.acorn.
  44.  acorn.co.uk/     ---------------   |   ----------------    co.uk/sprite.gif
  45.  drawfile.gif   /      Passes down http://www.acorn.     \
  46.                |             co.uk/movie.rply             |
  47.                |                    |                     |
  48.                |                    |                     |
  49.          http fetcher        http fetcher            http fetcher
  50.   This being a private       Passes | down all     Passes | down all the
  51.  subtask knows its parent  the data | received       data | received
  52.  can plot drawfile, so it           |                     |
  53.  sends its received data            |                     |
  54.  straight back to its     Passes up | when to stop    GIF=>Sprite
  55.  parent. If it were a       sending | data             convertor
  56.  public subtask it would      Replay=>Sprite        This takes the GIF
  57.  check what filetypes the       convertor           and converts it into
  58.  parent can load, and       This takes enough       a sprite, and sends the 
  59.  convert to sprite if it    data to convert the     data, as processed, back
  60.  couldn't handle drawfiles  first frame into a          to the parent
  61.                             sprite and also sends       / | \
  62.                             all the data processed  Delegated tasks
  63.                             straight back to the    The same as below, except
  64.                                   parent            obviously it's multiple
  65.                                   / | \             copies of the GIF=>Sprite
  66.                              Delegated tasks           convertor
  67.                           These are seperate copies
  68.                           of the Replay=>Sprite
  69.                           convertor called when the
  70.                           convertor above this is still
  71.                           processing but is asked to
  72.                           process another segment of
  73.                           data retrieved from ttcpip:
  74.  
  75. As you can see, processing of all data coming in performed simultaneously,
  76. which means that no matter how quickly the data comes in, it is all
  77. processed, not held up until the processing and conversion routines can deal
  78. with it. The speed and productivity gains are impossible to calculate. It
  79. also means that the parent html viewer may have bits of gif appearing in a
  80. seemingly random order, which I would suggest is not altogether bad.
  81.  
  82. Subtasks are also subject to constant monitoring - should one fail due to
  83. lack of memory, it's parent is notified and can do what it likes with the
  84. information eg; schedule a retry, or perhaps inform its parent (if a
  85. subtask). It may also display a message/put a question to the user via
  86. Tornado_Query.
  87.    Should a subtask crash, it gets the same treatment as other tornado tasks
  88. - except that again its caller is notified after everything has been cleaned
  89. up. Subtasks can also request that a postslot heap be set up, so they can
  90. store internal memory allocations.
  91.    Another feature of subtasks is that all vdu output is sent to its parent.
  92. This can be used to run normally single-tasking tasks eg; my hopefully
  93. forthcoming animals guessing game door for Newsflash will be the raw program
  94. in Basic as written in 1993, but with a parent 'supervisor' which starts up
  95. the program as a subtask, reads in all graphics input, converts any vdu
  96. colour sequences/cursor positioning into suitable ANSI commands, and spits
  97. that down the line to Newsflash.
  98.  
  99. Special subtasks
  100. -=-=-=-=-=-=-=-=
  101.  
  102. Special subtasks currently come in as file convertors. If a user drags a GIF
  103. file onto a tornado app which can only accept Sprites, then the convertor
  104. subtask (stored in tconvert:) list entry called by the 32bit hexadecimal of
  105. the GIF filetype is checked out to find out what that filetype can be
  106. converted to. If it can be converted to a format that is loadable by the app
  107. the file is going to, the GIF file is loaded into tfs: while multitasking,
  108. and the subtask, as specified by the subtask list, is started up. The parent,
  109. Tornado, sets up an area of memory to receive the file, and the subtask
  110. starts spitting out converted Sprite.
  111.    When the subtask finishes, the original GIF data is thrown away and the
  112. file is loaded into the app by Tornado (see the appropriate document about
  113. loading and saving). Voila!
  114.    On saving, in the save box a GIF filesprite is shown, and unless the user
  115. changes it, the file is saved to tfs:, converted back by the appropriate
  116. subtask (this time determined from the entry for the hexadecimal of the
  117. sprite filetype).
  118.  
  119. Other things about subtasks
  120. -=-=-=-=-=-=-=-=-=-=-=-=-=-
  121.  
  122. Another thing to be noted here is that Tornado is intelligent about subtasks.
  123. It caches the most recently loaded subtasks so that they may be accessed
  124. quicker, if the user so wants, in tfs: (if present).
  125.    As said above, subtasks may not be necessarily executed on the local
  126. processor. They may also be executed on a second processor, or on a processor
  127. running somewhere on a network. Many people laughed at my original claim that
  128. the processor may be running on the other side of the world, connected via
  129. Internet. This is not unrealistic. Because subtasks communicate by
  130. Tornado_SendSTMessages and Tornado_GetSTMessages, and think they are the only
  131. process running in the machine, they can be run by a suitable
  132. multitasker/server. A client running on the local machine can send the
  133. subtask code down the network to the server, wherein it is cached and can be
  134. kept for future use. All messages between parent and subtask can be run over
  135. the network. Easy!
  136.  
  137. Summary of subtasks: they are extremely powerful, and their importance in the
  138. Acorn world can only increase, if not within Tornado but by the probable
  139. implementation of TAOS for the Arm series of processors.
  140.