Should I acquire lock for logging.Handler.flush()?

[Vinay Sajip]

On Feb 22, 4:44 am, Fayaz Yusuf Khan <fayaz.yusuf.k... at gmail.com>
wrote:

> Anyway, I read the source and found many interesting things that ought to be
> mentioned in the docs.
> Such as flush() should be called from close() whenever it's implemented.
> (FileHandler.close() is doing it)

This is entirely handler-dependent - there's no absolute rule that you
*have* to call flush() before close(). Some underlying will do
flushing when you close.

> And how come close()/flush() isn't being called from inside a lock?

Why does it need to be? Are you aware of any race conditions or other
concurrency problems which will occur with the code as it is now?

> (Handler.close() calls the module level _acquireLock() and _releaseLock()s but
> nothing about the instance level acquire() or release())
> Or is it being locked from somewhere else?

The module level acquisitions are because module-level handler lists
are changed in Handler.close().

If locking is required in a particular handler class for close or
flush, that can be implemented by the developer of that handler class.
AFAIK there is no such need for the handler classes in the stdlib - if
you have reason to believe otherwise, please give some examples of
potential problems and with example code if possible.

Regards,

Vinay Sajip