Event Handling Patterns Asynchronous Completion Token E81 CSE 532S: Advanced Multi-Paradigm Software Development Event Handling Patterns Asynchronous Completion Token Chris Gill, Derek Chen-Becker, Frank Hunleth Department of Computer Science and Engineering Washington University, St. Louis cdgill@cse.wustl.edu Title slide

Motivation for Event Handling Patterns Context Programs often have limited knowledge, learn about things via events Limitations of synchronous architectures Latency and jitter due to blocking, deadlock potential But, a common trade-off is less complicated programs Common Intent for Event Handling Patterns Reconcile event handling, concurrency, distribution design forces in canonical ways, to reduce accidental complexity

Event Handling Patterns (continued) Asynchronous Completion Token (Design Pattern) Passes information between asynchronous activities Reactor (Architectural Pattern) Asynchronous notification of ready events De-multiplexing and dispatch mechanisms for initiation Acceptor-Connector (Design Pattern) Decouples connection establishment from connection use Decouples passive role from active role during connection establishment Often used with the reactor Proactor (Architectural Pattern) Asynchronous notification of completion events Small pattern languages involving event handling Active object + ACT (asynch computations) Reactor + Acceptor/Connector + ACT (distributed systems) Limitations of synchronous architectures: Threading overhead (context switch, OS thread overhead) Less scalable than asynchronous Asynchronous model matches better the flow of events in GUIs and network servers What tradeoffs are made when moving from a synchronous to an asynchronous architecture? Need to correlate asynchronous requests to replies Need to demultiplex completions Need to maintain state between requests and replies How does ACT help mitigate these? Provides mechanism to correlate requests to replies Can provide efficient demultiplexing

Photo Courtesy of Derek Chen-Becker and Frank Hunleth Asynchronous Completion Token (ACT) Photo Courtesy of Derek Chen-Becker and Frank Hunleth Also Known as the “Cookie” Pattern

When Should We Use ACT? Context Problem Event-driven systems Invocation and response are asynchronous E.g., functions dispatched using std::async, std::packaged_task, or in separate threads Problem Completion events must be de-multiplexed Service does not know what a client needs to be able to de-multiplex responses Communication overhead must be minimal De-multiplexing should be efficient

ACT Solution Service (eventually) passes “cookie” to client Examples with C++11 futures and promises A future (eventually) holds ACT (or an exception) from which initiator can obtain the result Client thread can block on a call to get the data or can repeatedly poll (with timeouts if you’d like) for it A future can be packaged up with an asynchronously running service in several ways Directly: e.g., returned by std::async Bundled: e.g., via a std::packaged_task As a communication channel: e.g., via std::promise A promise can be kept or broken If broken, an exception is thrown to client

Some ACT Representations Data ACTs The most straightforward variation, holds result directly Pointer ACTs E.g. use T* to pass event handler’s memory location Issues: portability, inheritance/interface polymorphism Iterator-style ACTs Index into an array, STL iterator, etc. Watch out for copy/move semantics, etc. Memento/Command ACTs Holds all necessary information for response handler upcall Pointer ACT: void* may take up different numbers of bytes depending on the platform. How to choose? Pointer – local; no concerns about getting bad pointers back; don’t care about type safety if void* Object Reference ACTs – have middleware support; distributed calls; like type safety Index ACTs – Easier to validate; needed if state structures are remapped with shutdown Memento ACTs – Small amount of state; ACT used over long periods of time

Potential Liabilities Memory (and ) leaks Especially in client, if service doesn’t return ACT Need to use RAII, reference counted smart pointers, etc., to ensure entries are cleaned up Race conditions and deadlock Global vs. local identity, expire/retry Application remapping Affects pointer ACTs, sequence numbers etc. E.g., application crashes and restarts may remap pointer addresses Security implications Authentication, authorization, privacy Security implications: Authentication If service can’t be trusted, need to verify contents. Easier with index ACTs Make sure that responses aren’t spoofed Authorization Authorization may change between ACT creation and response. E.g. web page authorization cookie Privacy ACT contents may represent private information Legal, corporate, or user policy may limit contents and exposure