Events in General

Agenda Post/wait technique I/O multiplexing Asynchronous I/O Signal-driven I/O Database events Publish/subscribe model Local vs. distributed events

Post/wait technique Operating systems and some DBMSes Wait for an event to happen Post an event; i.e., make it happen Problems multiple listeners not usually possible waiting for different types of events not possible without multiple threads posting before waiting/waiting for non-event

Quick Review User Space Kernel Space Hardware System Call Data Transfer Device I/O Char/Block transfer

Blocking and Non-blocking I/O Blocking send request and wait for completion Non-blocking send request and check later for completion Check later: –periodically (polling) –occasionally –deferred wait

I/O Multiplexing Unix select() kernel function Send I/O requests and continue executing Wait for one or more of multiple events and/or a timeout to occur events are read, write or exception kernel notifies caller when I/O initiates Demultiplex event and handle it handler copies data from kernel space to user space

Asynchronous I/O Register handler function, send I/O request to kernel and continue executing Kernel notifies handler function after I/O has completed kernel copies data from kernel space to user space Not really in most Unixes it’s a POSIX thing

Signal-driven I/O Register handler function for signal, send I/O request and continue executing Kernel notifies (signals) handler function after I/O has initiated Handler copies data from kernel space to user space

Database Events InterBase’s mechanism Post/wait technique Named events Applications can register for multiple events synchronous or asynchronous Events under transaction control Multiple postings of same event yields only one event

Publish/Subscribe Model Interested parties subscribe to service consumers (listeners) Publisher of service provides information supplier (source) Push: send out information Pull: request information Java Event Model: supplier pushes GUI events to consumer

Event Channels Familiar push model: one-to-many Channels allow: push or pull many-to-many Supplier 1 Supplier 2 Consumer 1 Consumer 2 Consumer 3 Channel

Event Channels: Advantages Multiple suppliers and multiple consumers Could: buffer incoming events for later delivery ensure quality of service hide communication models filter events route events make events persist

Local vs. Distributed Events Most event models don’t consider distribution Why is this? Industry solutions: CORBA ACE

Blocking I/O Example

Non-blocking I/O (Poll) Example

Non-blocking I/O (Select) Example