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 475202
To read all comments associated with this story, please click here.
RE[4]: My Preference
by Brendan on Tue 31st May 2011 03:31 UTC in reply to "RE[3]: My Preference"
Brendan
Member since:
2005-11-16

Hi,

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?


No - I only said that (bad) choice of message size can make async more complicated (than async with a different/better choice of message size).

"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.


Ok - it fits under the "limited by memory" constraint; but "limited by memory in the all supported systems" rather than "limited by memory in the current system". For example, if the OS supports systems with as little as 16 MiB of RAM, then you'd probably want to set the maximum message size to 8 MiB or less, even for large systems with 123 GiB of RAM, to make sure software designed for the OS works as designed on all supported systems.

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.


I use "tasks" as a generic name for "processes, threads, fibres or whatever else might make sense for the OS or for the context being discussed".. ;)

Someone posted links to a few papers that explore "threads vs. events" (or "theads vs. messages"). Don't let them mislead you - those papers are stupid, and sane people would want both (not one or the other).

- Brendan

Reply Parent Score: 2