Re: [boost] [Ann] socketstream library 0.7

From: Simon Richter (Simon.Richter_at_[hidden])
Date: 2005-06-09 18:12:57

Hi,

Pedro Lamarão wrote:

> But how do you actually implement asynchronous name resolution? Are you
> using asynchronous primitives from the operating system, or are you
> holding a worker thread?

By hand. When the resolver is called by the manager, it will take a
quick glance at the hosts file, then assemble a DNS packet with the
questions it could not answer and send that off. When the answer
returns, all the people that asked are given their answers, which they
will probably use to call connect().

>>My streambufs hold a pointer to an abstract "impl" class which
>>represents the actual socket. Concrete subclasses of that exist for
>>different socket types, so new address families can be added at runtime
>>(currently, only through my plugin interface, which I wrote about to the
>>list a few days ago).

> So each "implementation type" is strongly connected to a value for the
> family parameter?

Yes.

> template <typename FamilyT>
> class socket;

Nope. The family argument is not a template argument, as this allows
addition of new families without the need to recompile applications.

> Such a definition would make a "socketbuf" subclass of streambuf have
> one extra template parameter; and we would still have to specify at
> least the value for "style" to select a transport protocol.

stream vs datagram is a choice of different classes in the application,
as there is no representation for "boundaries" in iostreams.

> streambuf's are neither copy constructible nor assignable, so, they are
> effectively non-copyable.

You can copy the members by hand and register a callback that will
handle further copies and destruction.

>>I avoid spawning new threads from library functions like the plague, as
>>it is difficult to properly collect those threads in case of an
>>exception etc.

> Well, then you would require asynchronous primitives from the operating
> system... There *are* such primitives, of course.

Yes, or doing it by hand and circumventing the system administrator's
choice of resolution order. I think that is a big issue that should be
dealt with on a OS-by-OS basis, with doing it by hand being the fallback
and a separate thread, possibly monitored by the manager object, being
the choice for OSes that support threads.

> But we won't be holding a fd_set of descriptors, but a standard
> container of references to stream objects.

"fd_set"s are cacheable. We can update our cached objects when the state
of a stream changes, therefore reducing the complexity to O(1). :-)

> Of course, the prototype for select is much more complicated; it would
> be wiser to use poll, but then I'm unsure if poll is available everywhere.

No problem to support both. :-)

   Simon