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?
Permalink for comment 474877
To read all comments associated with this story, please click here.
RE[2]: Yes, but it would be ugly
by looncraz on Sat 28th May 2011 03:27 UTC in reply to "RE: Yes, but it would be ugly"
Member since:

Performance really depends on the exact implementation.

In my (private)LoonCAFE project I use an almost fully async API ( with optional blocking calls ).

Performance is actually significantly better with callbacks and signals overall and the applications feel much better - especially when things really get heavy.

It would seem that latency would increase but I have not experienced that at all. The overhead is extremely minimal for callbacks and signals, being no more than the overhead of calling a function - or a simple loop in the case of a signal ( signals really serve a different purpose, though ).

Which is to say, not much in my implementation. An extra 'call' ain't very expensive.

--The loon

Reply Parent Score: 2