Re: [boost] Logging library - Organization of effort

From: Andras Erdei (ccg_at_[hidden])
Date: 2002-04-11 10:57:27

On Thu, 11 Apr 2002 09:24:01 -0400, "Ernie Makris" <ernie_makris_at_[hidden]> wrote:

>>1. The bottom layer contains the sinks (a base-class for
>>user-defined sinks, and pre-implemented memory, file, tcp/ip
>>and a platform-dependent interactive display).

>>The first three sinks have no locking mechanism
>>(i assume that each thread will use a separate
>>logfile etc), but the last one exists in both
>>thread-safe and thread-unsafe forms.

>Do these sinks end up talking to a streambuf that knows how to append to 
>sinks? Just curious.

hack()s dtor invokes the sinks with the .str().c_str() from
the string buffers, so the sinks don't know about the buffers,
adn the buffers don't know about the sinks. hack() is needed
because the output should be line-orineted, so i have to detect
when a full LOG << instruction was completed. (Dunno the exact
wording of the standard, but temporaries more-or-less get 
destructed right after the whole expression is evaluated.)
An alternative solution would be to require that the user
ends every LOG << with a << flush or something, but i'd like
to avoid excess typing.

>I think locking may be required at the streambuf level. But, I could see 
>locking also at the sink level, particularly if the sink will be shared 
>amongst multiple logs. If multiple logs in different threads write to the 
>same sink, you could have races and overlapped output unless the sink itself 
>is locked.

The buffers are thread-specific (and cleared after each LOG statement), 
so no need to lock there. (Except when creating those permanent, reused 
buffers the very first time.) The locking is needed for shared sinks 
(like the tree-view).

br,
andras