I've posted some comments there explaining a design pattern I've found that pretty much solves the "callback hell". http://www.250bpm.com/blog:24/comments/show#

I've posted some comments there explaining a design pattern I've found that pretty much solves the "callback hell". http://www.250bpm.com/blog:24/comments/show#post-1784877 http://www.250bpm.com/blog:24/comments/show#post-1784877 The basic idea is to integrate a LIFO event queue into the event loop, whose events take priority over other events (fds, timers). Then whenever you want to write code something like that: func() { call_callback(); do_something(); } Instead you do: func() { push after_callback_event; return call_callback(); } after_callback_event() { do_something(); } The LIFO nature of the event queue guarantees the expected event processing order, that is, the after_callback_event() is invoked after call_callback(), including any events call_callback() itself pushes, recursively. The other thing that helps a lot is to reduce coupling in your code. With reduced coupling, the "what can be called back when I call this" problem becomes much simpler. Components can't call other components that they don't know about. I can say that by applying the LIFO and taking care to decouple my components properly, my event driven code is certainly not suffering from the "callback hell". Quite the opposite, I think it is nice and correct :) I'm talking about the programs in my open source project here, https://code.google.com/p/badvpn/ https://code.google.com/p/badvpn/ .