Are polling and event-driven programming different words for the same technique?

Question

I studied interrupts vs cyclical polling and learnt the advantages of interrupts that don't have to wait for a poll. Polling seemed to me just like event-driven programming or at least similar to a listener and what the polling does is actually much like listening to input or output. Do you agree or did I misunderstand any crucial difference between polling (cyclical listening) and event-driven programming (also listening with so-called listeners)?

Answer 1

Both the answers are correct and addresses the original question. I am attempting to add a few points/considerations on event-driven / polling as is generally utilized from a bit higher level, from application containers.

If we assume we have a table where states of some components are written and based on the state some action needs to be taken; this could very well be designed as Q based eventing system or thread based polling system.

In the polling system in face of system/container termination/shutdown, the polling thread will find the changes in the next cycle and act on it.

In case of an event based system, if the container terminates before the event could be processes, it would result in the loss of the event. However, having said that there are transactional queues which are available and the capability comes out of the box; implementation of transaction, in general is a non-trivial process.

Both the methods are very much viable and not superior/inferior to each other. However, there are considerations for each model.

Answer 2

Nope, quite the contrary interrupt driven programming is pretty much what event driven programming is at the hardware level. Both interrupt driven code and event driven code waits for event before running a code, while polling will attempt to query for event whether or not one actually exists.

However, it should be noted that interrupt- and event-driven programs are generally implemented in the lower level using a form of polling; there is no truly interrupt or event driven system that does not involve some sort of polling, although usually in hardware. In the case of interrupts, the CPU actually polls the interrupt line every clock cycle, and likewise with event driven programming because restarting a paused thread involves an interrupt being raised by the source of event (usually drivers).

You can say that interrupt- and event- driven programming is a disciplined way to poll that have lots of advantage compared to actually doing polling yourself.

Answer 3

Polling and interrupt handling are two ways to find out about events. Neither is in contradiction with event-driven programming, which is building your program around handling of incoming events.