In article <dnqfmd$l6e$1@sea.gmane.org>, "Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote:
"Eugene Alterman" <eugalt@verizon.net> wrote
There is nothing special about synchronous operations, and they have been implemented in similar ways in dozens of networking libraries.
See, I don't care much about other libraries -- I am not going to use them. But if this one becomes part of Boost, I may start using it, and so I would like it to have what I need, with a clean interface, and implemented in a clean way.
IMO this is completely beside the point. This is not the boost networking library, it's the boost async IO library, and as such whether it supports sync IO or not is completely irrelevant. There are really two possibilities here: 1) You may some day use an async IO library, in which case this library will be useful to you and you should review it for its merit with regards to its stated design intent or 2) You will never use an async IO library, in which case this library will never be useful to you, and you should still review it for its merit with regards to its stated design intent, while acknowledging that it does not necessarily fit your problem domain. However, right now you seem to saying that you are not interested in async IO, and that this library, whose stated intent is to provide async IO, is therefore unacceptable to you. You have a nail. This library is not a hammer. IMO, if you want a clean synchronous IO API, you should not be looking for it in an async IO library. Ben -- I changed my name: <http://periodic-kingdom.org/People/NameChange.php>