"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:dnq31k$f1f$1@sea.gmane.org...
My problem with the current approach is that synchronous operations seems to be viewed as second-class citizens. I understand that this is caused by the fact that asio is about the asynchronous IO. But asio is presented as the "best C++ networking library around", and in networking both synchronous and asynchronous approaches are used, and neither is superior for all possible cases.
Consider "Patterns for concurrent and networked objecs" by D. Schmidt, at al. Quite a few patterns described there are related to the synchronous processing.
I just want to point out (hopefully without getting off topic too much) that there is an important difference between what you mean by 'synchronous' and the way this term is usually used in this context (and in particular in the publication you are mentioning). By 'synchronous' you seem to mean *blocking* synchronous i/o while in those patterns it is understood as synchronous i/o event demultiplexing and handling, meaning that a synchronous i/o operation is issued only if there is a ready event and the operation would not block. As a matter of fact this is the way asynchronous operations are emulated in asio on platforms that don't support them directly. As has been already pointed out blocking i/o operations is a bad option for critical high performance servers since they waste thread resources. That is why you won't find them in the book - just take a look at the Half Sync/Half Async pattern and compare it to your implementation. As in general, you may use whatever approach you come up with as long as it suits your particular needs, but providing solutions that encourage best practices is what design patterns are for. And asio provides a solution based on one of such patterns (Proactor) that happens to be asynchronous.