On Sep 19, 2006, at 3:27 AM, Salvati Marc wrote:
Hellom
Thank you for answering. I tried to use log4cxx::Level::getDebug().
It does not change my problem.
Aas my Stream and Logger are static,
static log4cxx::logstream stream;
static log4cxx::LoggerPtr logger;
I was wondering if I had to "lock" each time I wanted to send a
logging message. It looks maybe like a beginners question, but I
have no problem and no need to lock with std::cout.
regards.
Sorry, I did not notice that an instance of logstream was static in
your example. log4cxx::Logger is designed to be thread-safe and can
be since every operation is atomic. However, since several method
calls on a logstream may participate in the generation of one
message, there is no effective means that logstream could be
internally synchronized and preserve the callers intent. The
anticipated use of logstream is that it would be declared within a
method body and a single instance would be exclusive to a single thread.
For example:
Log::stream<<"message"<<LOG4CXX_ENDMSG;
is equivalent to:
Log::stream.operator<<("message");
Log::stream::operator<<(LocationFlush(__FILE__, __LINE__, ...));
Even if all operator<<'s had internal synchronization, you could
still have other calls to the same logstream occurring between the
insertion of "message" and the insertion of the LocationFlush object
which triggers the call to Logger::debug().
The intended use of logstream would be like:
class Foo {
private:
static log4cxx::LoggerPtr logger;
public:
Foo();
void run();
}
log4cxx::LoggerPtr Foo::logger(log4cxx::Logger::getLogger("Foo"));
Foo::Foo() {
log4cxx::logstream stream(logger, log4cxx::Level::getDebug());
stream << "message" << LOG4CXX_ENDMSG;
}
void Foo::run() {
log4cxx::logstream stream(logger, log4cxx::Level::getInfo());
stream << "message" << LOG4CXX_ENDMSG;
}
Obviously that type of usage demands that construction of logstream
be as cheap as possible. Unfortunately, the STL stream base template
constructors seem to be pretty expensive. I like the semantics of
the current logstream, but the performance isn't where it needs to be
and it may not be possible to preserve full compatibility with STL
stream semantics and get reasonable performance. All that to say
that log4cxx::logstream is still experimental and subject to change
or removal.
