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
