Linked by Hadrien Grasland on Fri 27th May 2011 11:34 UTC
Permalink for comment 474816
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Linked by Thom Holwerda on 04/16/13 9:29 UTC
Linked by Thom Holwerda on 04/15/13 22:44 UTC
More Features »
Sponsored Links



Member since:
2005-06-29
That's the only way things ever work properly in the real world, asynchronous event-based message-passing systems. I don't ever use blocking calls. I always opt for non-blocking calls. If anything, it forces me to write robust code.
I've noticed the wild assumptions programmers make when writing code based on blocking calls is monumental. The obvious dangerous assumption is that the call will complete successfully, if at all! That's where the cards begin to fall because if that call does not complete, for 10 million and 1 possible reasons, your program just hung indefinitely or crashed.
I learned the hard way. Anyone, who has done any kind of desktop application development probably has an endless list of war stories about the perils of blocking calls.
However, I know many developers (usually with a background in web development) who hate callback based programming. They claim it's hard to understand.