For anyone who is interested, I did some testing with the
ConcurrentRotatingFileHandler from my ConcurrentLogHandler package (v
0.8.3). I've found that it does not fail when dropped into the
revised-logthred.py script.  However, it does spend most of the time
in what I call "degraded" mode because the file rotation fails--this
means that the log file is constantly opened and closed around each
write() call so that eventually the log file can be successfully
rotated.  This is very inefficient, but the design goal of the
ConcurrentRotatingFileHandler is to never loose log events at all
cost, whereas the RotatingFileHandler is a more general purpose
solution and can therefore adhere to more size-based file rotation,
and yields a better and more consistent performance.

What I found interesting is that the ConcurrentRotatingFileHandler
seems to be behaves the same with or without the thread locking around
the os.system() calls.  This is something that I need to look into
when I have some more time.  (I haven't actually timed or traced
anything yet, so it's hard to say for sure what's really going on; or
if something else was going on during my tests)

Robert, one alternate approach to consider given all the complexities
you have going on (by that I mean, multi-threaded process spawning
programs that you need to have the ability to redirect the
stdin/stdout streams...)  You might want to look into adding one more
process in the equation.  You could have your script start off by
launching a "central logging" socket listener (or use a system wide
listener), and then have that single process handle writing to and
rotating your log files.  Then it's just a mater of redirecting the
logging system to push the events to your logging process.  I know
this might not seem like the most appealing approach, but it may end
up being the one that requires the least amount of modifications to
your existing code... just a thought.  (Vinay, I know you've
recommended this approach before, are there any samples laying around
to help people get started with a simple central logging solution
based on (e.g. built on top of) Python's logging package?)