OSnews Asks: Could You Live Without Blocking Calls?
Linked by Hadrien Grasland on Fri 27th May 2011 11:34 UTC
General Development After having an interesting discussion with Brendan on the topic of deadlocks in threaded and asynchronous event handling systems (see the comments on this blog post), I just had something to ask to the developers on OSnews: could you live without blocking API calls? Could you work with APIs where lengthy tasks like writing to a file, sending a signal, doing network I/O, etc is done in a nonblocking fashion, with only callbacks as a mechanism to return results and notify your software when an operation is done?
E-mail Print r 2   58 Comment(s) http://osne.ws/j3o
Thread beginning with comment 474810
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Yes, but it would be ugly
by tbcpp on Fri 27th May 2011 13:08 UTC in reply to "Yes, but it would be ugly"
tbcpp
Member since:
2006-02-06

I think you're missing how async is done in modern languages. For instance the entire IO API in silverlight is implemented via async calls.

So instead of actually warming the cpu in a loop, instead you provide a callback where execution will continue. Semiphores and mutexes could be coded in the same way (using the () => C# lambda syntax:).

DoStuff()
mutex.Aquire( () => {
DoMoreStuff();
});

In C# 5 there are extensions for doing this in a simpler manner (something like this):

DoStuff()
await mutex.Aquire();
DoMoreStuff();

Basically this is just syntactic sugar around the first example. I don't think any serious async system uses loops they instead hand off the async callback handling to other VM or OS functions.

Reply Parent Score: 3