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 474881
To read all comments associated with this story, please click here.
Callback fragmentation
by ndrw on Sat 28th May 2011 06:56 UTC
Member since:

When implementing a callback-based API be careful not to fragment the callbacks too much.

Say, user starts an operation on some large data structure and requests notification when that data structure changes. Perhaps the callback function does some expensive tasks, like updating the GUI etc. The operation itself requires a lot of atomic operation to be performed on the data structure, thus it generates a lot of notification events.

If you implemented this naively and update the user after every changes to the data structure (1), the user function would needlessly be called multiple times, consuming a lot of CPU time.

If you notified the user only at the successful completion of the whole task (2), then the user wouldn't be at all aware of the progress of the operation he started.

What you probably want to do instead, is to collect the notifications like in (2) and emit user code notifications periodically + immediately after the whole operation has finished. This probably requires some concurrency in your code but it can be done cooperatively if your main loop supports timers and idle events.

Reply Score: 3

RE: Callback fragmentation
by Neolander on Sat 28th May 2011 09:48 in reply to "Callback fragmentation"
Neolander Member since:

I don't understand: why would the code require a notification each time a data structure changes after having started a big operation on it, instead of asking for a notification once the big operation is over? More important, why would they put a very intensive callback function on something as fine-grained as changing a data structure ?

If you can prove that this is a valid use case and not poor programming practices at work, a feature that gives notifications a "cooldown time" could indeed be the right answer.

Edited 2011-05-28 09:52 UTC

Reply Parent Score: 1

RE[2]: Callback fragmentation
by ndrw on Sun 29th May 2011 04:36 in reply to "RE: Callback fragmentation"
ndrw Member since:

Well, that's a simple MVC pattern at work, which is also a kind of an asynchronous framework. I wouldn't call it a bad programming practice, quite the opposite. It does what it is designed for - separating concerns. The idea is that you do what you want to do on the Model and leave the task of updating the View to the framework.

And it works well too, if only you remember not to use the naive implementation for anything but the simplest models.

Reply Parent Score: 2