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 475171
To read all comments associated with this story, please click here.
RE[3]: My Preference
by Alfman on Mon 30th May 2011 23:07 UTC in reply to "RE[2]: My Preference"
Member since:

"if the message size is too big (or unspecified/unlimited) it's hard to tasks to reserve space for receiving messages"

In my own async library, read calls return a buffer of sufficient size, so the recipient doesn't need to make any assumptions. But your right it is a problem otherwise.

Your previous post indicated that the message size is more problematic for async compared with threads, I still don't understand why?

"allocating buffers belongs to, and you risk running out of RAM"

This is possible, yes, but then the OS should be throttling IO as needed.

"With no limit, what happens when a 64-bit process sends a 12 GiB message to a 32-bit process? "

Fair point, however I'd say this fits under the "limited by memory" constraint. Either way, the same problem exists whether async or threaded.

"Locally delivered messages may not be guaranteed to be received. You send a message to a task, it's placed in that task's queue, then that task terminates or crashes before it gets your message from its queue."

It could be guarantied in the same sense as a postmaster guaranties delivery of certified mail to someone at the house. If the recipient subsequently dies before reading the mail, that's not the postmaster's problem. If this answer is problematic, then it shouldn't be a problem to implement an inband response.

Anyways, my response was to your post about failed network delivery.

"Can task B receive the message from task C before it receives the message from task A?"

Yes, but this is an application level detail. I know of no protocol stack (threaded or async) which guaranties the ordering of messages between three parties in the way you've described.

However, in theory, it would be possible for an async IO application/library to defer delivery of C->B until A->B is delivered.

Also, you're mention of "tasks" gives me the impression that you're envisioning some kind of CPU bound computation, which I do advocate using threads for.

Reply Parent Score: 2