80 likes | 102 Views
This project expands the single play functionality to manage multiple plays efficiently using reactive event handling and concurrency architecture. The design involves directors waiting to start a play, a producer managing plays and user interactions, termination protocols, and signal interception. The solution handles each case appropriately, transitioning from one play to multiple plays seamlessly. Key considerations include integrating event handling, interception hooks, message handling, and Ctrl-C signal management.
E N D
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
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
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
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
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
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
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
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)