[And this was my follow up in the private exchange, along with a new addition below.]
It was a pleasure (and informative) to read your reply. I certainly wasn't trying to propose asio as the best thing out there; my experience pales in comparison with yours when it comes to various io libraries. I guess this is a classic example of accepting others decisions, in this case the boost project's, without really thinking about the whole picture. My experience with asio has almost entirely been writing fairly little utility programs. As such, I really haven't been worrying about integration with other code or object lifetime issues. I've been away from the world of C/C++ for about three years now (off in Python/Ruby land), and the "fire and forget model" has crept much further into my thinking than I'd like to admit. Boost, in general, is heavily into the wrap/bind model. In the past this hadn't been an issue, as the core boost libraries have been more focused on algorithms and meta-programming. The boost thread library was the first real attempt to start adding more system level functionality, and bind was used to do little more than wrap the member function that represented the thread entry point. Overall I was really impressed with boost::thread, and as I've been thinking about starting a more serious implementation of some of the P2P protocols I've been working on, I've just naively assumed boost::asio was as well thought out and the way to go. [...and this part has been added since the original e-mail...] That being said, the problems you describe with the bind model in relation to object lifetime seem at least partly related to the way in which one sets up callbacks. I can imagine that creating a new closure and binding the data needed to handle the calls return could become extremely burdensome, especially if the return handler initiates another RPC. But couldn't this be solved by using standard entry points into the various handlers, where the entry points check the validity of the data and the handler before calling it? In a sense, this is duplicating the work that would be performed automatically in the signal/slot style you described, but maybe it would reduce the problems in the bind async style. Thanks again for the e-mail - I apparently need to think a more deeply before choosing a io library for my work. Cheers, Cyrus _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
