Re: [boost] Late asio review

From: Chris Cleeland (cleeland_at_[hidden])
Date: 2006-01-13 11:20:39

On Sat, 14 Jan 2006, Christopher Kohlhoff wrote:

> --- Chris Cleeland <cleeland_at_[hidden]> wrote:
> <snip>
> > > - Implement the Socket_Option concept for the option.
> > 
> > Maybe you could show an example in the docs for this?
> 
> Yep, no problem.
> 
> <snip>
> > I disagree.  First, I stated that KNOWING the details is important, not 
> > that one need to manipulate the details all the way down the line.  But 
> > even if I do need to manipulate details at different layers (all the way 
> > down to the wire), that need doesn't necessarily diminish the utility of 
> > a feature like asio.  Why should I be prevented from using an 
> > otherwise-useful feature simply because I need to tweak things at a lower 
> > level?
> 
> If it's just knowing the details and having the ability to tweak
> the implementation, then what I'm planning is:

When you say "tweak the implementation", are you talking about modifying the 
distributed code?  Or, are you talking about using language features to 
substitute alternative implementations for stuff normally provided by the 
lib?

> - To provide compile-time (i.e. #define), and in the long term
>   possibly runtime, ways to choose the implementation strategy.
>   However these mechanisms will be outside the library's public
>   interface, since they're tied to the implementation, and that
>   can change between releases.

This is quite different from what I'm talking about.  What this sounds like 
to me is that you'll provide a way for the user of the lib to select from 
whatever choices you, as lib implementer, decide to provide.  I'm talking 
about opening things up such that if somebody wants to provide an alternate 
implementation they can code behind an interface you dictate and hook it into 
your lib.

> - To implement DNS lookup using sockets. This might be a really
>   good solution for some platforms, but unfortunately not for
>   all. Using gethostbyname on Windows, for example, also
>   resolves NetBIOS names, and asio should provide identical
>   behaviour to the platform's own host resolution functions.

This is what I was thinking, but forgot about the platform-specific ways in 
which resolving might occur.  I suspect something similar would also be true 
under OS X so that it can find listings in NetInfo, Rendezvous, etc.

> > Can you expand on this a little more?  I'm having a hard time 
> > understanding what it means to have tss hold a pointer to something on 
> > the stack. I'll try to check out the code itself, too.
> 
> The only place TSS is used in asio is to determine whether or
> not the current thread is inside a call to demuxer::run() for a
> specific demuxer object. It works as follows:
> 
> - The TSS value holds a pointer to the top of a stack
>   implemented as a linked list.
>
> - When a demuxer::run() call starts it creates a linked list
>   node on the stack, and pushes it on to the top of the stack.
> 
> - When a demuxer::run() call exits it pops the node from the
>   stack.

How does the stack get destroyed?

Who allocates and deallocates the tss slot?

> See asio/detail/demuxer_run_call_stack.hpp for the
> implementation of this.

I will; should I fetch the version from CVS, or is the review code for that 
area still valid?

-- 
  Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris
     Principal Software Engineer, Object Computing, Inc., [phone]
      Support Me Supporting Cancer Survivors in Ride for the Roses 2005
    >>>>>>>>>    Donate at http://www.milodesigns.com/donate    <<<<<<<<<