Re: [boost] thoughts on logging library: orthogonal runtime configuration

From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2008-04-09 10:49:52

On 09/04/2008, vicente.botet <vicente.botet_at_[hidden]> wrote:
> Hi Christian,
>
>  ----- Original Message -----
>  From: "Christian Holmquist" <c.holmquist_at_[hidden]>
>  To: <boost_at_[hidden]>
>  Sent: Monday, April 07, 2008 11:46 PM
>  Subject: [boost] thoughts on logging library
>
>
>  > Hi,
>  >
>  > I saw that the previously proposed logging library went into the
>  > review queue again, so I thought of pointing out some remarks prior
>  > the actual review.
>  >
>  > First of all, I think that a boost logging library should come up with
>  > one, and one only, way of expressing a log line.
>  >
>  > BOOST_LOG(some, kind, of, args);
>  >
>  > Now, how should the interface of BOOST_LOG(...) look like? To find
>  > that out, I'll start by explaining how I would like boost log to
>  > behave from a users point of view, for instance using boost.Asio.
>  >
>  > #define BOOST_ASIO_LOG_ENABLE
>  > #define BOOST_ASIO_LOG_MIN_LEVEL boost::log::level::debug
>  > #include <boost/asio/asio.hpp>
>
>  I'm not sure it is a good idea to place these macros in the source code
>  files. First you can define the macros on several header files, needing some
>  test undef and so one. Which will be the result when two source files (.cpp)
>  defines different configurations? IMO the macros you purpose should be
>  defined at the build level of the executable.

Of course.
It was only an example of the defines.

>
>  I really think that we need runtime configuration and I suspect that this
>  configuration should be centralized. But I don't think that this is a
>  particular case of the logging library. logging and configuration are
>  orthogonal. A runtime configuration library will be welcome and should be
>  able to configure the asio log level as well as other configurable features
>  as for example the boost::log::level of a global log.
>
>  Let me show how I will use the current Boost.Log library interface if I were
>  the maintainer of asio library.
>  I will define un internal macro like that:
>
>  #ifdef BOOST_ASIO_LOG_ENABLE
>  #define BOOST_ASIO_LOG(LEVEL, MSG)                         \
>     if (boost::asio::log_level <= LEVEL) {                               \
>         BOOST_LOG(LEVEL) << "[asio] " << MSG                 \
>     }
>  #else
>  #define BOOST_ASIO_LOG(LEVEL, MSG)
>  #endif
>
>  I will place the definition of the boost::asio::log_level variable in a
>  specific header file, which should be included by the user in only one
>  comilation unit.
>
>  // boost/asio/log_level_def.hpp
>
>  #ifndef BOOST_ASIO_LOG_LEVEL_DEF__HPP
>  #define BOOST_ASIO_LOG_LEVEL_DEF__HPP
>
>  #ifndef BOOST_ASIO_LOG_LEVEL_DEFAULT
>  #define BOOST_ASIO_LOG_LEVEL_DEFAULT boos::log::level::debug
>  #endif
>
>  #include <boost/asio/log_level_fwd.hpp>
>
>  namespace boos {
>  namespace asio {
>
>  atomic_log_level_type log_level=BOOST_ASIO_LOG_LEVEL_DEFAULT;
>
>  }
>  }
>
>  #endif
>

Sure, this could work, but I think asio::log_level should be a
function returning the current level instead of a global variable.
Then it's up to the user to choose where from this variable is read
and how it's updated. There may be more things to consider, again
something for a log library to decide best practice.

>  As the boost::asio::log_level reading and writing could be done by different
>  threads the read and write operations must be atomics. So
>  atomic_log_level_type must be convertible to boost::log::level and must is
>  assignable from boost::log::level atomically.
>
>     typedef atomic<boost::log::level> atomic_log_level_type ;
>
>  An other history is how can we configure the boost::asio::log_level variable
>  at runtime?
>
>  Well this can be done in a lot of ways. But at the end what you realy need
>  is to do a the following
>
>     boost::asio::log_level = new_value;
>
>  Is for this raison that the atomic_log_level_type  assignation operator must
>  be atomic.
>
>  We can use also a configurator class which store a mapping between some key
>  and a reference of such variables.
>
>     rtc::runtime_configurator<std::string, atomic_log_level_type&> conf;
>
>  Note the mapped type is a reference to the real atomic_log_level_type.
>  The advantage is that now the owner of the configured variable do not
>  depends on how this variable is configured.
>  It is up to the user to make the association between the configured variable
>  and the configurator.
>  This runtime_configurator could be based on the property_tree library.
>
>  The user can add the configurable variables as follows
>
>     conf.register("boost.asio.log_level", boost::asio::log_level);
>
>  The runtime configuration library can provide a callable backdoor to
>  configure any registered variable using cli, as for example
>
>     $$ push boost
>     $$ push asio
>     $$ log_level = debug
>     $$ log_level
>     $$ pop
>     $$ asio.log_level = debug
>     $$ asio.log_level
>
>  The push and pop command are used to change the context.
>  the var = value command assign the value, and the variable command prints
>  its value
>
>  This backdoor will look up the corresponding configurable variable and read
>  o write depending on the command.
>
>  To allow symbolic values wee need manage with the conversion from
>  std::string to boost::log::level and vice versa. We can use the lexical_cast
>  library for this purpose as soon as the we have the output and input
>  operators defined for boost::log::level.
>
>  If the register is done at initialization time before the backdoor thread is
>  lunched, the runtime_configurator instance will be used only for reads, so
>  no thread safety problem at the map or tree_map level.
>
>  Then the user can start the backdoor as follows
>     boost::thread configurator_backdoor(rtc::backdoor)
>
>  The user can provide its own external configuration means with a graphical
>  interface if he consider convenient.
>
>  Do you think that a such runtime configurator variables library has a place
>  in Boost?

I haven't thought about it, but it sounds useful. It's probably an
often reinvented wheel.

>  This could be a complement to a larger configuration library starting from
>  program_options, extending to property_tree storage and making the CLI a
>  specific parser, other parsers can be reading from some configuration file
>  formats, the backdoor I'm proposing or other as has been already proposed in
>  this mailing list (CGI parameter parser).
>
>  <snip>
>
>  > Configuring the above with a compiled library like boost serialization
>  > is an interesting task as well, that I definitely think should be
>  > addressed. could be that the flexibility decreases some in such a
>  > scenario, or it could be configued in site-config.jam or whatever.
>
>  Once the serialization library provide traces or log, if you want to use the
>  serialization library with logs you should add a define at compile time
>  e.g. -DBOOST_SERIALIZATION_LOG_ENABLE and link with the serialization logged
>  variant e.g. -lboost_lserialization.
>
>

Agreed. Should the maintainer of serialization invent his own
build/jam/config thingie to make this possible? I think not.

>  > Is this along the line what boost.log has in mind, or will it be a
>  > logging library not to be used by the boost libraries themselves?
>
>  I think that this has nothing to be with the  Boost.Log library. It is up to
>  the other Boost libraries to use or not the loging library.

Sorry, I disagree, I think that it has everything to do with the log library.
It should show how boost libraries should use the library to make them
customizable for end users of boost.

>  The single flaw is that these libraries either must use a single global variable log or
>  extend their interface with a log parameter. This problem has already been
>  discused during the Boost.Singleton review.
>

Some boost libraries already use singletons. Religious views on
globally accessible data aside, what would be the flaw with a single
log instance?

>  >
>  > Regards,
>  >
>  > Christian
>
>  Do you think that this approach allows to configure the libraries using the
>  log library?
>
>  Best regards
>
>  _____________________
>  Vicente Juan Botet Escriba
>
>
>  _______________________________________________
>  Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>