At the low level, the OS kernel "knows" when something happens, because the device in question sends the CPU a hardware interrupt. So when, say a network packet arrives, the network controller sends an interrupt, and the OS kernel responds as appropriate. At the program level, it works quite differently - most application programs run an "event loop", where they fetch a message say, a message from the OS saying that "the mouse was clicked on this point in your application" , perform the appropriate actions in response to that, and then, listen for more messages.
If there is no message, the OS sleeps the thread until it has a message to deliver. Take a look at Interrupts this should explain how the hardware initiates certain 'events'. Often an event listener is registered with the object that generates the event. When the event occurs, the object iterates through all listeners registered with it informing them of the event. There's often higher level systems e. DBUS that listen for this and have event listeners listening to them.
I suspect that's a simple case of polling the mail box e. Programs like email checkers will usually be running background services that query their email server every X period checking for new mail. There are other ways of doing it, but for software level events, it's almost certainly going to be something like that.
Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Vector or javax. To fire off an event to its listeners, the component simply loops through its list of listeners and passes the event to each listener by calling the listener's event dispatch method. This example shows how to register, deregister, and fire events of type XXXEvent. When an event occurs, the component creates an event object and passes it to the fireXXX method, where it is passed to the listeners.
The example defines a generic recipe that all components can follow. The event holds all of the information necessary for a listener to figure out what happened. The information included is really event specific. Just think about the event carefully and design the event class to hold whatever information is necessary to fully describe the event to a listener.
Events normally extend the java. AWTEvent event class. An event listener interface defines the methods used by a component to dispatch events. Each event type will have at least one corresponding dispatch method in a listener interface. To listen for an event, a listener must implement the XXXListener interface and register itself with the component.
When an event occurs, the component will call the proper dispatch method. The methods are defined in an interface so that any object can receive the event.
As long as the listener implements the interface, the component will know how to dispatch the event to the listener. As you can see, there are dependencies between some of the pieces. The listener interface corresponds directly to the event. The event is necessarily the dispatch method's argument.
Setting up a dedicated monitoring subsystem in cases where nobody is interested in any events, however, would represent a pure waste of resources. If there are a only a few subsystems that are interested in events, the cost of having them watch for the events they're interested in may be less than the cost of setting up a general-purpose dedicated monitoring subsystem, but the break-even point will vary significant between different platforms.
An event listener is like an ear waiting for a message. When the event occurs, the subroutine chosen as event listener works using the event arguments. There are always two important data: the moment where the event happens and the object where this event occurs.
Other argument are more data about what's happened. In its simplest form, a publishing object maintains a list of subscribers' instructions to be carried out when something needs to be published. It will have a some kind of subscribe x method, where x depends on how the event handler is designed to handle the event.
The publisher may contain all, some or none of the logic for handling the event. It's most likely to contain a mixture of both. The event handler adds the method to its list of subscriber callbacks. When an event occurs, the event handler iterates over its list and executes each callback. For a real world example, when you subscribe to the newsletter on Stack Exchange, a reference to your profile will be added to a database table of subscribers. When it's time to publish the newsletter, the reference will be used to populate a template of the newsletter and it will be sent to your email.
In this case, x is simply a reference to you, and the publisher has a set of internal instructions used for all subscribers. Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. How does an event listener work? Ask Question. Asked 3 years, 10 months ago. Active 7 months ago.
Viewed 30k times. Based on the discussion in class, it seems that event listener works in a different way. Improve this question.
Gary Holiday Gary Holiday 1, 2 2 gold badges 7 7 silver badges 8 8 bronze badges. An event listener does not check at all. It gets called when the event that it is "listening" to fires. Yes, but how does it "listen", wouldn't it be constantly checking? All an event listener does is wait to be called by the event when it fires, much like any other method.
Until it gets called in this fashion, it does nothing at all. Every time you check to see if the button is pushed, it costs you clock cycles. The event handler listener only costs you when the button is actually pushed. RobertHarvey - not necessarily, as "listeners" still need constant polling on lower level. You just push complexity from your own layer of code deeper down to hardware interrupts or whatever. And yes, this will usually be more efficient, but not because listening is superior to polling, it's because polling on lower level is more efficient than polling from C and 15 layers of abstraction between you and hardware.
Show 12 more comments. Active Oldest Votes. Improve this answer. Robert Harvey Robert Harvey k 54 54 gold badges silver badges bronze badges. It might be worth mentioning the reason there is no cost until the button is pushed is because buttons are "special", the computer has interrupts and other special facilities the OS can use, that are abstracted into userspace applications. It's just that this polling is centralized and optimized, so that adding more event listeners does not add additional polling and complexity.
PieterGeerkens I'd guess that gntskn meant that as part of the game engine loop, there's a step that checks for any outstanding events.
Events would be processed during each loop along with all the other once-per-loop activities. There wouldn't be a separate loop for checking on events. Voo: All the more reason not to get into this level of detail in this post. Voo: I'm talking about buttons like the physical keys on the keyboard and mouse buttons.
Show 24 more comments. Alexander Alexander 3, 1 1 gold badge 16 16 silver badges 22 22 bronze badges. Does this require an inversion of control kind of schema? It seems that that would be the case.
That which calls the "listener" has to be at the head of control flow. If so, that is rarely discussed in this context and was the confusing aspect for me. If not, then I'm just on the wrong track. Add a comment. The longer explanation is a bit more involved. Where do client events come from? Where do application events come from?
How do drivers generate events? Sklivvz Sklivvz 5, 17 17 silver badges 34 34 bronze badges. This answer explains why there is no polling involved for mouse click events in a browser.
Tibos afaict it also applies to keyboard events, timer events, paint events, etc. Terminology event : A type of thing that can happen. These definitions don't depend on implementation, so they can be implemented different ways. Common scenarios Programming-logic events. The event is when some method gets called.
0コメント