Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Could someone help me understand what is the difference between the two, far as I understand it 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.

Did I get it right?

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?

Yet another question is, why are web apps built with non-blocking servers generally considered faster (is it just because of time spend on scheduling threads or something else?)

And finally, 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?

share|improve this question
add comment

2 Answers

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.

share|improve this answer
    
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 Apr 18 '12 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 Apr 19 '12 at 0:39
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

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.