Re: [boost] Late asio review

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-01-13 09:31:14

Hi Chris,

--- 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:

- To document the implementation strategies for each supported
  platform. There's a little bit in the design docs already.

- 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.

<snip>
> > The issue here is that hostname resolution is a potentially
> > lengthy operation. If resolution is only performed at
> > program startup, then that might be ok. However, if a server
> > needs to resolve hostnames on a regular basis, you would not
> > want to block the flow of control and delay other clients.
> 
> Okay, I can understand the motivation, but are there not other
> ways to implement besides firing off a thread?

The alternatives that I'm aware of are:

- To use a platform's native asynchronous host resolution
  functions, if available.

- 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.

<snip>
> 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.

- To determine whether the current thread is inside
  demuxer::run(), the TSS pointer is access and the stack
  traversed to see if the demuxer object is present.

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

Cheers,
Chris