Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Once you escape the realm of electrical signals and are dealing with software, is there really such a thing as a "push" architecture where there isn't periodic polling?

I can't think of any design where it's not polling at some level. It seems like it's always just a level or two beneath the actual abstraction/API you are dealing with. Sockets at the receiving end of most "push" connections just poll for incoming requests, etc.

share|improve this question

migrated from Jan 15 '12 at 4:12

This question came from our site for professional and enthusiast programmers.

Do you consider a hardware-triggered interrupt to be "polling"? – Oliver Charlesworth Jan 13 '12 at 22:22
I'd say no. But what software systems can actually make use of them (particularly in the realm of networked apps)? – John Cromartie Jan 13 '12 at 22:38
socket programming, and web sockets are "push". – zzzzBov Jan 15 '12 at 4:22
up vote 13 down vote accepted

I think Windows required applications to poll for IO until NT and Windows 95. Modern general purpose operating systems have pretty much eliminated the need for polling. When your application requests to read from a socket, the read function has to make a call to operating system kernel. The OS puts the calling thread into a suspended state. As network packets come in they trigger a hardware interrupt that is handled by the OS. If the packet is the one your application is looking for, the OS takes the thread out of the suspended state, and the read can proceed. In other words your application is in fact coupled to the realm of the electrical signals via the OS.

share|improve this answer
Thank you! This is a great summary. I have actually been reading "Code" by Charles Petzold and just got to the part about interrupts. This all makes much more sense now, and I can see how a network device and CPU and OS could all work together to implement a true push architecture. – John Cromartie Jan 19 '12 at 22:15

websocket architecture is a push architecture, actually so is exchange & outlook. These protocols stay connected to the server at all times and the server sends messages (pushes them) whenever there are messages...

share|improve this answer

I would also consider sockets that Charles already presented to certainly be "push" design. He walked you all the way from the realm of the electrical signals up, but another topic to consider are "push" designs which are purely application architecture decisions and happen at much higher abstraction layers.

Typical event frameworks would be considered push, since event source will fire events regardless of who is listening for them, or if the event sink is able to keep up with those events.

Another example, which is the area where I work in, is video streaming. We work with RTP (real-time transport protocol). It is UDP/IP based and by nature it is a push protocol. The sender will keep sending video at the rate it chooses without ever caring if the receiver is keeping up with it.

share|improve this answer

Sure there is. UDP socket applications in Unix, for example, can be pure-push. The best known would be the classic BSD Unix syslogd, which declares its willingness to accept incoming ("pushed") packets and processes them. No reverse communication at the application or protocol level (the "pusher" doesn't even know if the packet was correctly received and processed). At an API level within the receiving application, there may be polling, synchronous, or callback reception mechanisms, the latter two of which are pure-push.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.