Once upon a time I bumped into Introduction to Indy article and can't stop thinking about blocking vs non-blocking IO ever since then.
Looking for some good articles describing what are pros and cons of blocking IO and non-blocking IO and how to design your application in each case to get natural, easy to understand and easy to maintain code.
Would like to understand BIG picture...
The positives and negatives are pretty clear cut:
Blocking - Linear programming, easier to code, less control.
Non-blocking - Parallel programming, more difficult to code, more control.
Well blocking IO means that a given thread cannot do anything more until the IO is fully received (in the case of sockets this wait could be a long time).
Non-blocking IO means an IO request is queued straight away and the function returns. The actual IO is then processed at some later pointer by the kernel.
For blocking IO are that you either need to acept that you are going to wait for every IO request or you are going to need to fire off a thread per request (Which will get very complicated very quickly).
For non-blocking IO you can send off multiple requests but you need to bear in mind that the data will not be available until some "later" point. This checking that the data has actually arrived is probably the most complicated part.
In 99% of applications you will not need to care that your IO blocks. Sometimes however you need the extra performance of allowing yourself to initiate an IO request and then do something else before coming back and, hopefully, finding that the IO request has completed.
Anyway, just my tuppence.
I haven't found good articles.
I've asked here for suggestions on how to lay out async IO code: http://stackoverflow.com/questions/883156/tidy-code-for-asynchronous-io
The answers actually weren't very warming.
Async IO is a beast to get your head around and debug, especially if you use edge-triggers (e.g. Linux's epoll with EPOLLET flag). But it what you pay for in code complexity you win in performance and scalability.