Overview and Discussion of Lab 3 Design

1. Overview and Discussion of Lab 3 Design • Expand the work from a single play to multiple plays • I.e., extend lab 2 program to read multiple script files • The program should scan all configuration files in all plays • Size of the thread pool should be large enough to play all parts in any two consecutive fragments in any of the plays • Reactive event handling & concurrency architecture • Directors should wait to start a play until told to do so • A Producer will interact with directors and with end user • A menu of running and available plays will be managed • Termination protocol & signal/message interception • User can tell Producer to stop a play while its running • User can hit Ctrl-C in any terminal window • Lab 3 solution must handle each case appropriately

2. From One Play to Multiple Plays • Still 1 Director per program like lab 2 • But multiple plays are available to run • One per script file given in argc, argv • Still 1 thread pool • Pre-parse all script files for pool size • 1 play at a time • If not running a play, then any of the plays can be started on demand Director thread pool Plays Hamlet Macbeth P M P O L D R P M S P O L M R P M D P O L S R P M P K O S R Q P M R O G P K Q G Q

3. Adding Distribution & Reactive Event Handling • Multiple processes • Each with plays, a director, threads • Producer process • Interacts with user, directors of plays • Reactive event handling in each • Directors told when to start/stop a play by producer • Producer informs user, relays user commands Producer cin/cout User Now playing: Hamlet Macbeth socket socket Director Director thread pool thread pool

4. Initialization & Initiation Sequences • User starts the Producer process • Prints IP address • User starts some Director processes • Contact the Producer at its IP address, register • User selects plays • Producer tells a suitable Director to start each play • Producer tells user the plays started Producer cin/cout User Now playing: Hamlet Macbeth socket socket Director Director thread pool thread pool

5. Basic Termination & Shut-Down Sequences • User tells Producer to stop a play • Producer tells the play’s Director, which stops threads • User hits Ctrl-C in a Director process • Stops play if active • Tells Producer its about to go away • Releases memory & other resources before ending gracefully Producer cin/cout User Now playing: Hamlet Macbeth socket socket Director Director thread pool thread pool

6. Global Termination & Shut-Down Sequence • User hits Ctrl-C in Producer process, or tells it to quit • Producer tells all Directors to stop and shut down • Directors stop and shut down as in their own previous Ctrl-C scenario • When Producer hears back from all Directors, releases resources & then ends gracefully Producer cin/cout User Now playing: Hamlet Macbeth socket socket Director Director thread pool thread pool

7. Key Design Considerations • How to integrate reactive event handling within HS/HS or LF concurrency architecture • Think about what benefits and risks are involved • E.g., design/debugging complexity vs. performance vs. … • Where to put interception hooks, for multiple events • Where to receive and handle messages from other processes (i.e., Producer to Director or vice versa) • Where to put/detect flags for handling Ctrl-C signals • Design decisions are again largely yours to make • If the specification differs from what you think should be done, please ask about and/or suggest new ideas • If it’s a reasonable alternative, I’ll approve it in advance • Take notes as you go, write up design in your lab report

8. Some Suggestions • Evolve (and debug) your solution incrementally • Start with as much of lab 2 as is working well • Add and test handling of multiple plays in a row • Add and test registration of directors with producer • Add and test producer interacting with user and directors • Add and test advanced features (signal handling, starting and stopping plays more frequently, signal handling, termination scenarios of various granularities) • Please start early so I can be of the most help in answering questions, discussing ideas, etc. • Initialization, initiation, termination, shutdown, and restart scenarios all will need to be tested thoroughly • Where to put interception points will require key choices • Those choices may affect how rest of design evolves • Some choices may need to be revisited (modularity helps)