From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-12-15 11:50:49
"Christopher Kohlhoff" <chris_at_[hidden]> wrote
> Let me state as clearly as possible: the synchronous operations
> are not implemented in terms of the asynchronous operations.
> They call the underlying synchronous system call with little
> So, the nub of your issue appears to be the conceptual
> difficulties you perceive in having the socket constructor take
> a demuxer, and for the interface to include both synchronous and
> asynchronous operations.
Right, I have a conceptual problem with having to allocate an object that is
> Let's consider the alternative approach proposed: to split the
> socket class into separate sync_socket and async_socket classes.
That's one way of doing things. The other might be to move read/write
operations outside the socket class.
> The drawbacks of this approach are increased redundancy and
> complexity in the programming interface. If this approach were
> already in place, I can imagine that I would be getting
> questions about why there are so many socket classes, and which
> one is the most appropriate to use.
> There are trade-offs in every design decision. I elected to give
> synchronous and asynchronous operations equal weight, and
> combine them in a single interface. This has the added advantage
> of allowing mixed-mode programming, where synchronous operations
> can be used alongside asynchronous in a single application. As
> you point out, there are situations where synchronous is more
> appropriate, and these differences can occur within an
> I don't think that the need to pass a demuxer to the socket
> constructor is conceptually difficult to explain. It's there for
> the asynchronous operations, if and when you need them.
My complain is not about explanation, but about a conceptual cleanness of
the interface. One has to allocate an object which is not used, and this
rings a bell.
> I also do not agree that it is onerous to have to pass the
> demuxer to the constructor, or to pass it wherever it's needed
> in the program. You can make it a global, declare a new one for
> each use, or even use one associated with an existing object, as
> stream_socket s(my_acceptor.demuxer());
> Therefore I stand by my design choices as the best balance
> between usability, functionality and flexibility.
I respect that.
> Now, to turn to more philosophical matters, namely synchronous
> versus asynchronous approaches.
> As you pointed out, synchronous socket programming is easier to
> debug. However, there are also disadvantages, notably increased
> resource usage (with a thread required per connection)
I actually meant fixed amount of worker threads taking tasks from the
queue -- not a thread per connection.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk