Could someone help me understand what is the difference between blocking and non-blocking frameworks?

So far, I understand that when request comes to a blocking framework it creates new thread for that request and processes it, if second request comes to server before the first one has finished it execution it will create another thread.

Now for non-blocking server when one request comes to a web server it wont create a thread but will wait for a request to complete and in case another request comes to a framework before first has finished executing it wont be able to process it before it returns result of first request.

Another question I have is what exactly happens with second request in non-blocking framework does browser just waits for server to respond till request expires or something else happens?

If non-blocking frameworks can process one request at a time, how can web apps built with non-blocking frameworks process more requests than ones built with blocking frameworks (assuming that above statement is correct). Does that mean that for each instance of blocking framework on our server we would actually deploy multiple instances of non-blocking framework?

3 Answers 3


What is a Non-Blocking framework?

Explain it like I'm 5: Imagine you want to make a deposit to your bank account. You walk in and notice there is no queue of people waiting line.

The sign over the bank teller says: "Non-blocking teller". You walk up and ask the teller to process your deposit, the teller responds: "I'm busy with another transaction, try again later".

You wait some amount of time, and try again later. You make your own decision if you want to keep trying to get your transaction processed, or not. You try and the 5th time you try, your transaction is processed immediately.

The "Blocking teller" would have told you to "stand in line as a FIFO queue". The non blocking teller says: "try again later". Which bank teller would you prefer to interact with, and why?

Definition: A non-blocking framework provides a service and returns a result immediately instead of expecting the other programs requesting a resource to wait.

In other words: When a client side program makes a call to the framework, the call will always return immediately with whatever response it has for you without expecting you to sit there waiting for something. This guarentee is nice for programmers who don't want to worry about programming around the situation where the framework expects us to wait for 5 minutes.

A concrete programming example: Suppose your framework wants to provide mutually exclusive access to a file saved on the server side. An example of a "non blocking call" would be try_lock. If the client side wants access to the file, the framework responds: "No, try again later", rather than putting you in a queue and expecting you to sit there waiting.

The client side keeps trying for the lock, until it gets it, once it gets it, it does its business and unlocks it. The benefit of this is that whatever you try has an immediate effect.

Drawbacks to non blocking frameworks: When there is too much work to be done for a non-blocking framework, clients are denied, and fairness is not enforced, only the clients who badger the server the most get access to the service. It's not fair.


Did I get it right?

I think you've got it backwards.

"blocking" refers to prohibiting other things from proceeding while processing a task.

A server listens on a port for a request. When it receives one, it can either (a) process the request (not listening for more requests while doing so, blocking further requests until the work is completed) or (b) spawn a thread to handle the request, and immediately return to listening on the port for more requests.

Alternatively, it could dispatch the request to an already spawned thread in a pool of threads it's managing.

  • Thanks for your answer, but still how can blocking frameworks then process more requests/sec if they can only handle on request at a time. Do I need to run multiple instances of it to address the issue or there are other ways to solve the problem?
    – Havir
    Commented Apr 18, 2012 at 21:42
  • It can't. You'll need to either parallelize the servicing of requests, or process requests in series, and live with Nrequests/sec where N is defined by however long it takes to handle a request. It sounds to me like possibly you're hesitant to repair the code that's implementing the main dispatch loop for your service - I wouldn't be - there are numerous awesome examples of how to do a service really well out there.
    – pbr
    Commented Apr 19, 2012 at 0:39

I think what you are describing is confusing two different things - Synchronous/Asynchronous calling mechanisms and the Reactor design pattern (which is a way for a long running service application to handle multiple service requests).

Blocking is another name for a synchronous call whereby the caller waits until the task finishes before resuming.

Non-blocking is another name for an asynchronous call whereby the caller returns immediately after making the call and may then be informed via an event (or callback) when the task has finished.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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