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?
Thread beginning with comment 474860
To read all comments associated with this story, please click here.
Yeah, *I* could
by Obdurodon on Fri 27th May 2011 21:09 UTC
Obdurodon
Member since:
2008-05-07

So could every kernel/embedded programmer, because that's how those environments have worked just about forever and the closer you get to the hardware the more true that becomes. The problem is that you don't always control what APIs you need to use, and even in the systems world many people still provide blocking APIs. You can either reinvent whatever complex thing they're doing, rip it apart to add non-blocking calls, or spin off a thread that can afford to block. It's ugly, but no uglier than reinventing the wheel - especially when that wheel is doing something specific to a proprietary black box somewhere or is a proprietary black box itself. Any decent framework should encourage async styles of programming (which isn't to say lame single-dispatcher-thread crap) but allow for sync where it's necessary.

Reply Score: 2