Re: [boost] singleton asio::demuxer as default? (was:asioformalreview begins)

From: simon meiklejohn (simon_at_[hidden])
Date: 2005-12-20 00:56:06

----- Original Message ----- 
From: "Eugene Alterman" <eugalt_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, December 20, 2005 6:39 PM
Subject: Re: [boost] singleton asio::demuxer as default? 
(was:asioformalreview begins)

> "Peter Petrov" <ppetrov_at_[hidden]> wrote in message 
> news:do81b5$4ir$1_at_sea.gmane.org...
>> Arkadiy Vertleyb wrote:
>>> That should not be difficult to achieve with derivation or some sort of
>>> policy.  Looks like async_socket might be derived from sync_socket (or
>>> contain it).
>>
>> This was also my thought - public derivation. I.e., the current socket
>> class is refactored into two classes - base (sync_socket) and and
>> derived (async_socket). The sync_socket class won't know anyhing about
>> demuxers (it doesn't need to).
>
> Except that demuxer is currently also a service repository.
> And wouldn't the service repository if decoupled from a demuxer be a 
> legitimate candidate for a singleton?

Do the current synchronous methods make use of the demuxer?
If not, then what about a separate constructor with no demuxer that
marks the socket as for synch use only. Then throw if asynch methods
are touched.