Re: [boost] [netlib] 0.8-beta now available!

Subject: Re: [boost] [netlib] 0.8-beta now available!
From: Bruno Santos (bsantos_at_[hidden])
Date: 2010-11-15 12:04:31

Seg, 2010-11-15 Ã s 21:40 +0800, Dean Michael Berris escreveu:
> On Mon, Nov 15, 2010 at 8:55 PM, Rutger ter Borg <rutger_at_[hidden]> wrote:
> > On 11/15/2010 01:04 PM, Dean Michael Berris wrote:
> >>
> >> The documentation has also been updated to feature a brand-new
> >> reference manual detailing the implementation, caveats, and public API
> >> of the HTTP client and server templates.
> >>
> >
> > It looks interesting on first sight.
> >
> > I'm wondering why you chose an active object pattern for implementing
> > asynchronous clients, and not the proactor pattern as enabled by Asio.
> 
> The reason for this is to keep the same interface that is enabled by
> the synchronous implementation. Note that the client is an active
> object, but it doesn't create one thread per connection.
> 
> A new client implementation in the next release will allow for adding
> a callback function and provide a thread pool to the client so that
> application-specific handlers can be invoked from that thread pool
> instead of on the I/O thread dedicated to Boost.Asio's io_service.
> 
> > If
> > someone wants to open many connections (e.g., a web crawler), one thread per
> > connection probably isn't the way to go.
> 
> Yes, but you don't need to create one thread per connection. You can
> schedule a lot of requests on the same thread, put the responses on a
> container, and check if each response is ready -- and only process
> those responses that are ready.
> 
> The response objects hide the fact that there are futures involved and
> the API remains in the "synchronous" domain, although the
> implementation underneath is asynchronous.
> 
> > This issue may be related to some
> > of my concerns surrounding the current client API, where I am missing the
> > (non-future) async_ methods.
> >
> 
> I just implemented as part of this release a 'ready(response)'
> function that allows you to check whether the response returned by the
> client in the asynchronous client implementation is ready. That should
> suffice for the meantime until I get to implement the callback
> supporting API.
> 
> > Wouldn't a name like http++ be covering better what the library does?
> 
> Not really. This is not just an HTTP client/server, another maintainer
> is developing an XMPP implementation, and later I'll be developing an
> ESMTP client that follows the same API that the HTTP implementation
> does.
> 
> The process being followed is as prescribed by "generic programming"
> where we start with a specific implementation and then lift the
> generic parts out from the specific implementations.
> 
> >
> > Kind regards,
> >
> 
> Thanks very much for the feedback, it is very much appreciated! :)
> 
> I hope this helps!
> 

The thread pool is a BAD IDEA. I'm very interested in your library, I
would like to use it with other async services I have implemented using
Boost Asio. For this a need to specify which io_service your library is
going to use and no threads whatsoever. I like the idea of boost Asio,
having a single io_service where I can put as many threads to run as I
would like (this would usually be a number of threads equal to the
number of cores).