Check these out next

Introduction to fa and dfa

deepinderbedi

Lenguaje ensamblador EMU8086

Santy Bolo

Symbol table management and error handling in compiler design

Swati Chauhan

LISP: Introduction to lisp

DataminingTools Inc

Micro programmed control

Syed Zaid Irshad

SQL Transactions - What they are good for and how they work

Markus Winand

Introduction to Google App Engine

rajdeep

Transport layer

reshmadayma

Event and signal driven programming

Jun. 9, 2012•0 likes•12,582 views

Download to read offline

Technology

Elizabeth SmithFollow

Software Engineer

More Related Content

Event and signal driven programming

Event and Signal Driven Programming The wheel already exists…
Feedback is precious No real code was written or harmed for this talk
Computer Science 201 Event based programming …. ??? …. PROFIT!
Structured programming  simple,hierarchical program flow structures  sequence  selection  repetition  procedural  adds sub-routines or functions  object oriented  modularizes components of code
Event Driven Programming Wait for Events Handlers Accept are Called Event Dispatch Event
Transitioning to events  code flow is controlled by the user, not the program  software can sit “idle” until an event occurs  allows software to react  why?
Asyncronous vs. Synchronous  event-driven !== asynchronous  structured !== synchronous  concurrency through  Async I/O (epoll, IOCP, kqueue, et al)  threads  forking (multi-process)
Interrupts  asynchronous signal/event indicating need for change in execution or need for attention  “The ship is going to explode”  A signal is a software interrupt delivered to a process
Design Patterns The Evolution of Event based programming
Publish/Subscribe  type of event programming  this is NOT observer  publisher and subscriber are decoupled  subscribers express interest in a state change/event/message/signal  each subscriber receives a copy
Subscriber Publisher Broker Subscriber Subscriber
(Main) (event/message) loop  poll  blocks until something arrives  dispatches  main is added if it is the highest level of control in a program
Subject/Observer  this is a subset of publish/subscribe NOT the other way around  in this case, the subject maintains the observers and notifies them of state change/event/message/signal  more tightly coupled then publish/subscribe
Observer1 Subject Observer2 Observer3
Event/Handler  events are spawned by the system  events are dispatched to handlers which are attached to them  handler can go by many names – callback, closure, function  events might have priority, might interrupt depending on the dispatch method used
Object Handler1 (Event1) Send Event2 Handler2 (Event1) Dispatcher Handler3 (Event1) Handler4 Send Event (Event 2)
Dispatcher  getsevent  determines which handlers get called  either attached  determined by type  stored in some manner  calls the handlers
Signal/Slot  signal – something you know is going to happen that is attached to a class  slot – method in a class that can be connected to a signal  connect a signal to a slot (wire it up)  emit the signal  requires oo
Reactor  Resources  Synchronous Event Demultiplexer  Dispatcher  Request Handler
Reactor Service Service Service Request Request Request Demultiplexer Dispatcher Various Handlers
Copy the Giants Use examples of existing event driven code http://sdrv.ms/LIJUlA http://emsmith.net/slides/dpc2012/event-code.zip
Windows API Message Pump of Doom
On to the Code  Concepts  Main “Loop” for processing  Message Queue holding messages  Windows (objects) post to queue  Queue passes messages around  Each window has a winproc to handle messages sent to it (switch of doom)
Gobject Event Handler madness
On to the Code  Concepts  Dispatcher  Register event by name  Attach a handler  Emit event
QT For those who like a little ++ with their C
On to the Code  event– virtual function in a class you reimplement to handle the event  signal – wired to a callback (slot) by a metaobject class, no loop necessarily required  slot – the actual implemented function for an event or a callback attached to a signal
Best Practices What to do in your own code
Name It properly  Publish / Subscribe  Dispatcher  Decoupled  (Main) Event Loop  Subject / Observer  stateless  State Machine  Event / Handler  Message Pump  event loop  Reactor  Signal / Slot  Tightly coupled objects  Traits
Standard interfaces  Observer? Use SplSubject and SplObserver  Pub/Sub?  Event/Handler?  Signal/Slot?
Borrow from other languages  Any C based language translates REALLY well to PHP  If you can’t depend on an extension, but want to “drop it in” – do the same API in a different namespace and class_alias as appropriate  Upgrading from stone wheels to vulcanized rubber is great, but don’t reinvent
The future?  Best new hope for clean, easy eventing implementations? Traits  Some good wrappers around existing C libraries (libevent, dbus, glib/gobject, qt, winapi, .NET)  Pulling in good ideas from other languages, PHP evolves
The Wild Wild West Experiments are coming
Eventing Libraries  https://github.com/christopherobin/Event Emitter  https://github.com/rdlowrey/Artax  https://github.com/Wordi/LooPHP/tree/m aster/LooPHP  https://github.com/nwhitingx/prggmr  https://github.com/igorw/evenement
Framework’s New Thing  ZF2 – Event Manager  Symfony 2 – Event Manager  Kohana Events  Aura (Aura.signal)  CodeIgnitor events  I could go on….
Extensions galore  Php-gtk (gobject)  http://gtk.php.net  libevent http://pecl.php.net/package/libevent  eio  http://pecl.php.net/package/eio  libev  https://github.com/m4rw3r/php-libev
node.php  https://github.com/JosephMoniz/node.ph p  PHP extension using libuv (joyent based platform abstraction eventing layer ) and http parser used for node  So essentially it IS node in a php extension
react-php  http://nodephp.org/  Originally called nodephp (to great screams), now is called react-php  Is actually passing off to another server  Written in php
Bring it on  Good Libraries  Blog posts  Articles  Extensions
I HAZ BETA CODE 4 U mojolive.com
Contact Me  http://emsmith.net  http://joind.in/6249  auroraeosrose@gmail.com  IRC– freenode – auroraeosrose  #coapp and others

Editor's Notes

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
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
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
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”
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.
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)
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
interrupt is an asynchronous signal indicating the need for attention or a synchronous event in software indicating the need for a change in execution.
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
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.
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
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
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
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
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
This is a fairly common eventing pattern – and what most use
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.
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.
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
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.
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.
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
Let’s talk about windows message queueThis is actually somewhere between the event/handler paradigm and the straight subject observer
Quick concepts – there is a WinMain() functionWe have a queue we grab code out of
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.
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.
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
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.
4:45 – wrap up with a quick tour of places you’ll see events/signals/observer patterns “in the wild”
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
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
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.
4:45 – wrap up with a quick tour of places you’ll see events/signals/observer patterns “in the wild”
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
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!!
And more are coming – try them, play around, you may be really surprised
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
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
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?
Let’s wrap it up and wake up – wrap up around 4:50 with questions (and they’ll be hungry)

Event and signal driven programming

Recommended

More Related Content

Slideshows for you(20)

Similar to Event and signal driven programming(20)

More from Elizabeth Smith(20)

Recently uploaded(20)

Event and signal driven programming

Editor's Notes