XML

kent logo

CO538 Anonymous Questions and Answers Keyword Index

This page provides a keyword index to questions and answers. Clicking on a keyword will take you to a page containing all questions and answers for that keyword, grouped by year.

To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

Keyword reference for poison

2003

Question 65 (2003):

I can't figure out the best way to have all the values read out once the cells are full (using the pipeline implementation). The way I thought of doing was to have the `poison', marking the end of the input, sent along to each cell along the pipeline. This would cause a toggle in each cell to switch meaning that the cell would output the `poison' to the next cell and then output what it contains and then outputs everything it recieves from then on. Only problem is that doing this means the `poison' is moved to the end of the queue to the front and outputted first into the `display', meaning no outputs are put on screen.

Could you give me a few hints as to a way I could trigger all cells to start outputting their contents without moving the `poison' from being the last output? Sorry if this isnt clear!

Answer 65:

As you suggest, poison should be the last thing happening. The `read.data' process only outputs the poison after it has output all the data. Your cells should follow suit -- the `poison' tag should only be sent once any data in the cell has been sent (effectively the reverse of what you appear to be doing at the moment).

Keywords: q6 , poison


Question 55 (2003):

For q6 do we need some form of end marker ? like the sort pump. If so how do we represent an end marker?

Answer 55:

Yes, you do need an `end-marker'. It is provided for you, however -- as the `poison' tag. The `read.data' process will output this once it has finished reading all the names (before terminating). The `display' process, when it receives this tag, also terminates.

See also the answers to Question 53 (2000) and Question 61 (2000)

Keywords: q6 , poison

2000

Question 61 (2000):

Hi. If we receive a poison should we output it? It is not too clear in the question how the program should terminate. Could you clarify please.

Answer 61:

The higher-level protocol used on NAME.NUMBER channels is that, most of the time, only string variants flow. A poison variant only gets sent once and is the last item to be sent down the channel.

A process receiving poison should take that as a hint to die, tidying up any outstanding business first. That business might include outputting more string variant(s) on its output and, finally, a poison variant - so that the next process in the pipeline knows that it, also, should terminate.

You should notice that the given processes, read.data and display, both behave in this way. So should your processes. Then, all the processes in your system will terminate cleanly when all the data has been processed and your whole program will end.

All of the above will have been discussed in your seminar groups earlier this term.

Keywords: q6 , poison

Referrers: Question 55 (2003)


Question 53 (2000):

For question 6, what value is poison (so that I can test for it)?

Answer 53:

You don't need to know this. poison is a tag name, part of the NAME.NUMBER protocol. It doesn't have a number representation (apart from an internal one that you can't get at) - it just has a name.

See the main cycle of the display process that's in your q6.occ starter file. That shows how to input from a channel carrying this protocol and how to distinguish a string message from a poison one. See also slide 10-21 from the course notes and section 7.3 from the "OCCAM2.1 Checklist" in your course booklet.

Keywords: q6 , poison

Referrers: Question 55 (2003) , Question 57 (2000) , Question 62 (2000)

Valid CSS!

Valid XHTML 1.0!

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.
Last modified Mon May 20 13:50:29 2013
This document is maintained by Fred Barnes, to whom any comments and corrections should be addressed.