1 Summary

zmedia is very happy with the zplayer (and bookz_player) from PA5. However, you have discovered some aspects of your current implementation that you are unhappy with. So, you are going to refactor your code.

2 The Problem with the Current Implementation

The system currently claims to use an event-driven architecture, however, that is only loosely true. In particular (as you recall from the reading early in the semester), an event-driven architecture makes use of an event queue, and your implementation does not. Instead, when an event is generated, the event receiver is "informed" directly using a function call (i.e., handle_event()).

This approach, while simpler than using an event queue, could cause a serious problem. In particular, consider the Loading state. Things start fine -- in response to an 'l' character, the handle_event() function calls the entry_to() function. However, consider what happens when the user enters a character that doesn't correspond to an existing .bookz file. The system calls handle_event() passing it an 'F' character, which, in turn, results in a recursive call back to entry_to(). Further, if the user continues to enter characters that don't correspond to an existing .bookz file, the recursion will get deeper and deeper.

While these calls will "unwind" properly, it is possible for the stack to overflow if the recursion gets too deep. Hence, this is a defect that must be corrected.

3 Specifications/Constraints

Since this is a refactoring of existing code, the functionality of the zplayer and bookz_player must remain unchanged.

Your refactored code must satisfy the following specifications/constraints.

1. The system must use a pipe/FIFO for the event queue. Event generators must write a single character at a time (representing an event) into the "write end" and event receivers must read a single character character at a time from the "read end".
2. The system must have one process that plays only the role of event generator. Specifically, it must read a character at a time from standard in and write that character to the "write end" of the pipe/FIFO.
3. The system must have one process (executing the implementation of the state model) that plays both the role of event receiver and event generator.
   1. As an event receiver, it must read a character from the "read end" of the pipe/FIFO and pass it to the handle_event() method.
   2. As an event generator it must, when appropriate (e.g., for the 'F' and 'S' events that are generated in the Loading state), write a single character at a time to the "write end" of the pipe/FIFO.
4. The system must use one or more semaphores to control access to the Interaction Terminal (IT). It may also one or more semaphores to control access to the event queue.

Of course, for obvious reasons, the bookz_player must still execute in its own process.

4 Submission

The .zip file you submit must be named pa6.zip. In addition to the source code and makefile, the .zip file must contain four screenshots that capture the state of the OS at different times.

Each screenshot must capture the following three things.

1. The relevant current processes.
2. The relevant current semaphores.
3. The relavant current pipes/FIFOs.

You must submit four screenshots in total.

1. before.png must be taken before you run zplayer.
2. ready.png must be taken when zplayer is in the Ready state.
3. playing.png must be taken when zplayer is in the Playing state.
4. after.png must be taken after zplayer has terminated.

You must not submit any data files.

5 Help and Hints

You have had very little freedom in previous assignments. For this assignment you have considerably more latitude, making it considerably more difficult. Given this, you should allocate more time for this assignment, and you should spend more time thinking before you start typing. Specifically, you should give careful consideration to each of the following points/issues.