Re: [boost] Late asio review

From: Hickman, Greg (greg.hickman_at_[hidden])
Date: 2006-01-11 17:19:40

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Chris Cleeland
> Sent: Wednesday, January 11, 2006 12:47 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Late asio review

[snip]

> If you do that, you still get into the situation of having to 
> replicate what is essentially a system interface at a level 
> that is supposed to provide abstractions and a certain 
> measure of system independence, right?  I'm not sure that the 
> Right Thing(TM) is to allow direct access to file descriptors 
> or handles, but the fact remains that over the years I've 
> come up with enough time that I've needed to access something 
> platform or system-specific related to sockets that I've 
> needed something like this.
> 
> I don't think it makes sense for asio to become a kitchen 
> sink for those sorts of things, but one also shouldn't be 
> forced to break encapsulation or abandon asio because one 
> needs functionality from one of the lower level tools that 
> the asio designers/developers didn't anticipate.

If possible, I'd lean toward the ability to both take advantage of the
platform where it makes sense and rely on portable abstractions
everywhere else.  What if I need to demultiplex file I/O events as well
as socket events in a TCP-based echo client?  Without the socket handle,
I don't know how to use asio sockets for that.