Hi Christopher, "Christopher Kohlhoff" <chris@kohlhoff.com> wrote
--- Jeremy Maitin-Shepard <jbms@cmu.edu> wrote:
It seems that a possible solution is to provide a `dummy' demuxer that simply makes asynchronous operations fail. This `dummy' demuxer could then be the default parameter to the socket constructors, thus eliminating the need to specify a demuxer for synchronous-only use.
It seems that this would indeed clean up the interface for synchronous-only use.
After pondering this for a few days, I've come to the conclusion that doing the above isn't that dissimilar to having a singleton demuxer. Such a demuxer would be used as the default argument to constructors, as Jeremy said. It certainly wouldn't be any different in terms of runtime performance. What do people think of this approach?
Could you provide some (high-level) justification of why it is beneficial to have a socket dependency upon a demuxer? Maybe I am missing something, but IMO such a dependency is unnatural even for asynchronous IO. Hiding it behind default parameter, singleton, etc., just masks what I believe is a design problem. If you absolutely believe this dependency is necessary for async IO, having two separate classes, such as sync_socket and async_socket would be much cleaner. But again, I can't see what justifies such a dependency even for async IO. Regards, Arkadiy Regards, Arkadiy