Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow

Subject: Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Boris Schaeling (boris_at_[hidden])
Date: 2011-02-11 19:34:10

On Fri, 11 Feb 2011 08:07:34 +0100, Artyom <artyomtnk_at_[hidden]> wrote:

> [...]asio is very well designed asynchrous event loop that IMHO
> should be used for any asynchronous operations as it allows
> to do in "async" way almost any task.

This was exactly what I always thought, too. Now I believe that I made the  
classic mistake of seeing everywhere nails because of the Boost.Asio  
hammer. As much as I like Boost.Asio I don't think anymore that we should  
try to integrate everything in Boost.Asio just because we managed to add  
the word "asynchronous" to the description of a feature. There are certain  
requirements, and if they are not met I think Boost.Asio is the wrong  
answer.

Boost.Asio is based on I/O service objects which provide services to I/O  
objects. If we create a singleton outside of I/O service objects what's  
their purpose? We don't need them anymore. We could use the singleton  
directly. That's what Dmitry Goncharov had proposed with his  
signal_handler.

Or let's imagine Boost.Asio wouldn't exist and we would think about a  
signal handler. Everyone would probably agree that we need a singleton.  
But would anyone argue that we also need an I/O service object and an I/O  
object?

Given the easy to use Boost.Asio API some developers would still prefer to  
use it. And it could all still be built on top of such a singleton. I, for  
one, would always prefer direct access to the singleton though -  
especially if it's that easy to use as Dmitry's and Boost.Asio can't  
provide me anything extra.

Boris

> [...]