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