Event and Signal Driven Programming Zendcon 2012

Editor's Notes

• #2: Although event driven programming has been around for many years, it's relatively new as an "engine" in the PHP community. Learn the concepts of event programming, and by extension signal driven programming, from the toolkits that have made it standard - Qt, winapi, .NET, GTK+ - and learn how to apply them to your next PHP project. Also learn about extensions and libraries to use for speed4:00 startShort “whoami”Who am I, and why should you listen to me?Windows buildsCairo, PHP-Gtk, Win\\GuiUsing PHP since php 4 betaHow I got involved in PHP community and why you should tooHow I got interested in event programming – my foray into desktop, winapi and gtk coding
• #3: These are my goals for the talk – Each new eventing design pattern is introduced, explained, an example given in another language, and then some discussion on how you would do this in PHP.Finally I’ll wrap up with Some notes: this is marked as “advanced” for a reason. You will see some C code, some JAVA, get a 15 minute computer science lecture, and see very little PHP. If you thought this was code heavy or an in depth lecture on event driven programming you’re out of luck
• #4: In computer programming, event-driven programming or event-based programming is a programming paradigm in which the flow of the program is determined by events—i.e., sensor outputs or user actions (mouse clicks, key presses) or messages from other programs or threads.Event-driven programming can also be defined as an application architecture technique in which the application has a main loop which is clearly divided down to two sections: the first is event selection (or event detection), and the second is event handling. In embedded systems the same may be achieved using interrupts instead of a constantly running main loop; in that case the former portion of the architecture resides completely in hardware.Start 4:02 or so – concepts of event driven/event based programming
• #5: In the beginning there was structural programming"Sequence" refers to an ordered execution of statements.In "selection" one of a number of statements is executed depending on the state of the program. This is usually expressed with keywords such as if..then..else..endif, switch, or case.In "repetition" a statement is executed until the program reaches a certain state, or operations have been applied to every element of a collection. This is usually expressed with keywords such as while, repeat, for or do..until. Often it is recommended that each loop should only have one entry point (and in the original structural programming, also only one exit point, and a few languages enforce this).The last can also be termed “iteration”
• #6: Event-driven programming can also be defined as an application architecture technique in which the application has a main loop which is clearly divided down to two sections: the first is event selection (or event detection), and the second is event handling. In embedded systems the same may be achieved using interrupts instead of a constantly running main loop; in that case the former portion of the architecture resides completely in hardware.
• #7: What if instead of tightly controlling the run of a program, the software just sits idle until the user does something? Inother words, the flow of the program is controlled by user-generated eventsThis is probably the most important conceptual part of even-driven programming: the user is in control of your code.This has vast-implications on the type of code you write. For one, you can't expect the user to follow a predefinedexecution path (unless you go to great pains to enforce one). Instead, the system must be much more open-ended.This means more robust error-handling--you can NEVER assume the user has entered data in a certain order orprocessed one event over another, etcAt first glance, even-driven programming seems more complex than structured programming, and in a sense this istrue. However, an event-driven structure eases complexity by allowing you to program in the context of what the useris doing. If the problem can be thought of in the user's terms, that can make programming it a much more satisfying,and less-error prone process.The biggest answer to “why events” is twofold – first for a gui application (which is where event programming really took off) it makes sense for the program to react to actions taken by a user Let’s contrast this to a basic web application with a simple request -> response lifecycleThe second reason for “why events” is related to extendability – when events are done properly ANYTHING can be attached to them – this makes features such as hooks and plugins and apis far easier to implement in a system, instead of conforming to some functional api or extending a class, etc, you simply attach to the events you want to listen to (the strength of observer pattern is here)
• #8: And here is where people make their mistake – not all event driven programming is synchronous, not all procedural/structural is asyncThe ability to be asynchronous is tied to use a parallel/concurrent programming method and has absolutely nada to do with your choice to do structured or event-driven code
• #9: interrupt is an asynchronous signal indicating the need for attention or a synchronous event in software indicating the need for a change in execution.
• #10: In computer programming, event-driven programming or event-based programming is a programming paradigm in which the flow of the program is determined by events—i.e., sensor outputs or user actions (mouse clicks, key presses) or messages from other programs or threads.Event-driven programming can also be defined as an application architecture technique in which the application has a main loop which is clearly divided down to two sections: the first is event selection (or event detection), and the second is event handling. In embedded systems the same may be achieved using interrupts instead of a constantly running main loop; in that case the former portion of the architecture resides completely in hardware.Start 4:02 or so – concepts of event driven/event based programming
• #11: Pub/sub is a messaging pattern where senders(publishers) of messages do not program the messages to be sent directly to specific receivers(subscribers). Published messages are characterized into classes,without knowledge of what, if any,subscribers there may be. subscribers express interest in one or more classes,and only receivers messages that are of interest ,without knowledge of what, if any, publishers there are.Pdated automatically. the decoupling of publisher from subscribera simple mailing list is an excellent example of publish subscribe.
• #12: Issues to watch for:When you publish, are you publishing to everyone that is supposed to get the message? This is a system start/failover issue. Different nodes come up at different times, which means they will register at different times. Data can be lost. Publish is a push technology, which means a chatty sender can overload the system. This may also cause memory and network problems (drops)Message order is often important. If the publisher maintains order, then how does it deal with a situation where one or more consumers have drops? The entire cohort will be held back waiting for retransmission.This is an interesting model for things that need to keep stuff decoupled and cross network… but when we start needing to intercommunicate it gets a little messier
• #13: This is fairly self explanatory. Event driven programming (and event/handler, signal/slot by extension) use some kind of a main loop in their program to get the events in and the handlers/slots pushed out
• #14: in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.this is best known way of implementing an eventing systemThe essence of the Observer Pattern is to "Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and up
• #15: Unlike the pub sub – where there’s an intermediate queue that decides who gets what, and the publisher is isolated – the subject calls directly in after registeringNotices what we took OUT of the pubsub model is the broker – here they’re speaking directly to each other
• #16: dispatchers tend to be one per process, but can also be one per threadso event happens dispatcher takes event and passes to handlers that have been attached to the event type
• #17: This is a fairly common eventing pattern – and what most use
• #18: Some applications (for example, applications that control hardware) may treat the event streamas effectively infinite. But for most event-handling applications the event stream is finite, with anend indicated by some special event — an end-of-file marker, or a press of the ESCAPE key, or aleft-click on a CLOSE button in a GUI. In those applications, the dispatcher logic must include aquit capability to break out of the event loop when the end-of-event-stream event is detected.In some situations, the dispatcher may determine that it has no appropriate handler for the event.In those situations, it can either discard the event or raise (throw) an exception. GUI applicationsare typically interested in certain kinds of events (e.g. mouse button clicks) but uninterested inothers (e.g. mouse movement events). So in GUI applications, events without handlers aretypically discarded. For most other kinds of applications, an unrecognized event constitutes anerror in the input stream and the appropriate action is to raise an exception.
• #19: Signals represent callbacks with multiple targets, and are also called publishers or events in similar systems. Signals are connected to some set of slots, which are callback receivers (also called event targets or subscribers), which are called when the signal is "emitted.“Signals and slots are managed, in that signals and slots (or, more properly, objects that occur as part of the slots) track all connections and are capable of automatically disconnecting signal/slot connections when either is destroyed. This enables the user to make signal/slot connections without expendOlder toolkits achieve this kind of communication using callbacks. A callback is a pointer to a function, so if you want a processing function to notify you about some event you pass a pointer to another function (the callback) to the processing function. The processing function then calls the callback when appropriate. Callbacks have two fundamental flaws: Firstly, they are not type-safe. We can never be certain that the processing function will call the callback with the correct arguments. Secondly, the callback is strongly coupled to the processing function since the processing function must know which callback to call.ing a great effort to manage the lifetimes of those connections with regard to the lifetimes of all objects involved.
• #20: this nice diagram is from the qt website btw, which pionered the termNote that like straight subject/observer we don’t necessarily NEED a dispatcher here, things are linked directly object to object
• #21: The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs. The service handler then demultiplexes the incoming reResources: Any resource that can provide input from or output to the system.Synchronous Event Demultiplexer: Uses an event loop to block on all resources. When it is possible to start a synchronous operation on a resource without blocking, the demultiplexer sends the resource to the dispatcher.Dispatcher: Handles registering and unregistering of request handlers. Dispatches resources from the demultiplexer to the associated request handler.Request Handler: An application defined request handler and its associated resource.quests and dispatches them synchronously to the associated request handlers.
• #22: This is twisted, libevent/libev, node, eventmachineThis is select, epoll/poll, IOCP on windows (well for a GOOD library, bad libev), and kqueueTo combine multiple signals for transmission over a single line or media.To separate two or more channels previously multiplexed. Demultiplexing is the reverse of multiplexing. The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs.The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated request handlers.The Reactor Pattern is a design pattern for synchronous demultiplexing and dispatching of concurrently arriving events. It receives incoming messages/requests/connections from multiple concurrent clients and processes these messages sequentially using event handlers.The purpose of the Reactor design pattern is to avoid the common problem of creating a thread for each incoming message/request/connection. It receives events from a set of handles and distributes them sequentially to the corresponding event handlers. Thus, the application using the Reactor need only use one thread to handle concurrently arriving events.Basically the Reactor pattern allows an application to handle concurrent events while retaining the simplicity of single-threading.
• #23: In computer programming, event-driven programming or event-based programming is a programming paradigm in which the flow of the program is determined by events—i.e., sensor outputs or user actions (mouse clicks, key presses) or messages from other programs or threads.Event-driven programming can also be defined as an application architecture technique in which the application has a main loop which is clearly divided down to two sections: the first is event selection (or event detection), and the second is event handling. In embedded systems the same may be achieved using interrupts instead of a constantly running main loop; in that case the former portion of the architecture resides completely in hardware.Start 4:02 or so – concepts of event driven/event based programming
• #24: Let’s talk about windows message queueThis is actually somewhere between the event/handler paradigm and the straight subject observer
• #25: Quick concepts – there is a WinMain() functionWe have a queue we grab code out of
• #26: Originally part of gtk itself, it was split into glib and gtk – glib holds base functionality including the signal/event handling, basic C abstraction, etc since version 2.0 of gtkThe GLib event loop was originally created for use in GTK+ but is now used in non-GUI applications as well, such as D-Bus. The resource polled is the collection of file descriptors the application is interested in; the polling block will be interrupted if a signal arrives or a timeout expires (e.g. if the application has specified a timeout or idle task). While GLib has built-in support for file descriptor and child termination events, it is possible to add an event source for any event that can be handled in a prepare-check-dispatch model.[2]Application libraries that are built on the GLib event loop include GStreamer and the asynchronous I/O methods of GnomeVFS, but GTK+ remains the most visible client library. Events from the windowing system (in X, read off the X socket) are translated by GDK into GTK+ events and emitted as GLib signals on the application's widget objects.
• #27: Originally part of gtk itself, it was split into glib and gtk – glib holds base functionality including the signal/event handling, basic C abstraction, etc since version 2.0 of gtkThe GLib event loop was originally created for use in GTK+ but is now used in non-GUI applications as well, such as D-Bus. The resource polled is the collection of file descriptors the application is interested in; the polling block will be interrupted if a signal arrives or a timeout expires (e.g. if the application has specified a timeout or idle task). While GLib has built-in support for file descriptor and child termination events, it is possible to add an event source for any event that can be handled in a prepare-check-dispatch model.[2]Application libraries that are built on the GLib event loop include GStreamer and the asynchronous I/O methods of GnomeVFS, but GTK+ remains the most visible client library. Events from the windowing system (in X, read off the X socket) are translated by GDK into GTK+ events and emitted as GLib signals on the application's widget objects.ach signal is registered in the type system together with the type on which it can be emitted: users of the type are said to connect to the signal on a given type instance when they register a closure to be invoked upon the signal emission. Users can also emit the signal by themselves or stop the emission of the signal from within one of the closures connected to the signal. James (again!!) gives a few non-trivial examples of accumulators: “ For instance, you may have an accumulator that ignores NULL returns from closures, and only accumulates the non-NULL ones. Another accumulator may try to return the list of values returned by the closures. ”If a detail is provided by the user to the emission function, it is used during emission to match against the closures which also provide a detail. If the closures' detail does not match the detail provided by the user, they will not be invoked (even though they are connected to a signal which is being emitted). This completely optional filtering mechanism is mainly used as an optimization for signals which are often emitted for many different reasons: the clients can filter out which events they are interested in before the closure's marshalling code runs. For example, this is used extensively by the notify signal of GObject: whenever a property is modified on a GObject, instead of just emitting the notify signal, GObject associates as a detail to this signal emission the name of the property modified. This allows clients who wish to be notified of changes to only one property to filter most events before receiving them. As a simple rule, users can and should set the detail parameter to zero: this will disable completely this optional filtering.
• #28: Qt uses a code generator called MOC or he meta-object compiler to turn the markup you create for signals/slots into “meta objects” with everything includedSignals and slots are Qt mechanism, in process of compilations using moc (meta-object compiler), it is changed to callback functions.In Qt, events are objects, derived from the abstract QEvent class, that represent things that have happened either within an application or as a result of outside activity that the application needs to know about. Events can be received and handled by any instance of a QObject subclass, but they are especially relevant to widgets. This document describes how events are delivered and handled in a typical application.So events and signal/slots are two parallel mechanisms accomplishing the same things, in general an event will be generated by an outside entity (e.g. Keyboard, Mouswheel) and will be delivered through the event loop in QApplication. In general unless you set up the code you will not be generating events. You might filter them through QObject::installEventFilter() or handle events in subclassed object by overriding the appropriate functions.Signals and Slots are much easier to generate and receive and you can connect any two QObject subclasses. They are handled through the Metaclass (have a look at your moc_classname.cpp file for more) but most of the interclass communication that you will produce will probably use signals and slots. Signals can get delivers immediately or deferred via a queue (if you are using threads) A signal can be generated
• #29: First of all let's define what we mean by 'Qt event' exactly: a virtual function in a Qt class, which you're expected to reimplement in a base class of yours if you want to handle the event. It's related to the Template Method pattern.Note how I used the word "handle". Indeed, here's a basic difference between the intent of signals and events:You "handle" eventsYou "get notified of" signal emissionsThe difference is that when you "handle" the eventWhen a signal is emitted, the slots connected to it are usually executed immediately, just like a normal function call. When this happens, the signals and slots mechanism is totally independent of any GUI event loop., you take on the responsibility to "respond" with a behavior that is useful outside the class.
• #30: 4:45 – wrap up with a quick tour of places you’ll see events/signals/observer patterns “in the wild”
• #31: Pub sub if the event system is decoupledEvent/handler Signal/slot for tightly coupled with objectsSince observersare statelessReactor – gets events concurrently and multiplexes them into the main loopname it for what it is! don’t be making stuff up
• #32: we should have some of these standard interface lying about – the way things are done REALLY doesn’t changeHow would you define some “standard” interfaces for this stuff?Pull open editor and sketch some out if timebottom line – create a nice marker interface at the very least that can tell people “what this does” if you’re writing a libraryif you were to do it right, you’d kind of chain things down with objects, but their implementations would be much differentlimitation of PHP I guess
• #33: Here’s where I lecture on no matter how good your system is – stand on the shoulders of giantsRemember how long the kernel or xlib or gtk/glib have been around. They’ve already worked out the kinks. Look at things like accumulators, etc.
• #35: 4:45 – wrap up with a quick tour of places you’ll see events/signals/observer patterns “in the wild”
• #36: The eventemitter one is traits and 5.4 and so far I like it – although it’s really a subject observer pattern (event and listener since he’s copying node terminology and features)The second one is a 5.3+ basic event -> handler implementation with dispatcherThe event loop one is HIGHLY interesting – it has the gobject idea of “sources” for the loop so is better suited for networking style applicationsThe prggmr one is an excellent example of non-OO eventing code! If you’re into functional programming it’s probably the best fitEvenement is super simple and again copies the node.js idea of eventingKind of sad there is no good gobject port, or win32 port
• #37: Basically all the new frameworks have some sort of “event” systemMost are not event/handler, or signal/slot – in fact most tend to the basic subject/observer pattern we’ve had in PHP for ages, the difference is in the way it’s being integrated and used for control in the codeugh, the aura implementation is entirely event-> handler (has a dispatcher) NOT signal-slotGrrrrr!!
• #38: And more are coming – try them, play around, you may be really surprised
• #39: This is pretty interesting and would be a LOT of fun to play with, in fact I think I’d like to play with it a bit if I have time
• #41: Still a very young child – trying to do “nodejs” with php – to mixed results, some odd choices made in my opinion but fun to play with
• #43: 4:50 – wrap up and questionsTO make PHP more event driven in general there’s still a lot that needs to be doneAlthough there’s a lot of support coming from some of the frameworks, in general there aren’t good, solid stand along eventing libraries available in PHp the way there are in other languagesAlso there aren’t a lot of blog posts and articles detailing the right way to do things and what event programming is all about (and why it’s good)And finally PHP needs some good C warriors (or just some mediocre ones with time to sit in irc and code)but userland as well – where is php’s twisted? or php’seventmachine?
• #44: Let’s wrap it up and wake up – wrap up around 4:50 with questions (and they’ll be hungry)