Creating a logging library and have questions

[sybrandy]

On 02/03/2010 12:03 AM, Rainer Deyke wrote:
> sybrandy wrote:
>> 1) I use the current core.thread library and put all my messages in a
>> buffer that the thread checks periodically, pulls off a new message, and
>> then writes it to a file.  There will be some work to make sure nothing
>> collides with each other, but I think I can manage it.
>
> Wouldn't this allow logging messages to be lost before a hard crash?  To
> me, that would greatly reduce the utility of the logging system.

If done improperly, yes, it would.  My hope is that if I did go with 
this method, I would try to find a way to ensure no data was lost. 
Oddly enough, I'm currently having that problem with the single-threaded 
version for some reason.  The test program will stop and some of the 
logging statements never make it to the file.
>
>> 3) Something else.  I really don't have much experience with threading,
>> so I'm being very careful and really want to understand it.  This
>> library looks to be a good way to learn, however if it's not the best
>> way to do things, then what would be?
>
> Global mutex associated with the logging system.  Lock, output, unlock.
>   There are scalability issues with that approach, but I don't see why it
> wouldn't work in this situation.  (Plus, if you have a message queue,
> you probably need to protect that queue with a mutex anyway.)
>
>

Understood.  My goal is that if I do put the writing in another thread, 
I do my best to ensure it will scale.  I have a tendency to put a lot of 
logging statements in code when I'm trying to debug something, so I 
don't want to slow things down too much nor do I want to lose anything. 
  In short: I want the log writing to be as out of the way as possible.

Casey