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

[Fayaz Yusuf Khan]

I'm writing a custom logging Handler that sends emails through AWS Simple
Email Service using the boto library.
As there's a quota cap on how many (200) emails I can send within 24hrs, I
think I need to buffer my log messages from the emit() calls (Or is that a bad
idea?).
And I was reading the Handler documentation and was confused if I should call
the acquire() and release() methods from within a flush() call.
--
Fayaz Yusuf Khan
Cloud developer and architect
Dexetra SS, Bangalore, India
fayaz.yusuf.khan_AT_gmail_DOT_com
fayaz_AT_dexetra_DOT_com
+91-9746-830-823

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAABAgAGBQJPQ0Z5AAoJEFp5PFlEQdURTJ4H+wcneCDLQqDEh8yQnyYDlUbZ
ZX5L6Z65+rtZNYwiRDeS56KgRpsalBO2AB+oPJRVklgztAVuW5hHUO98eky3a0NJ
g5mCC/311jUupZA+sQ89eEH0vwPuwqqyYS2QUqbQTzDBWtidQGpmtevBJBh3LDvs
OLZyglit98lw35a/vB4C8PRTeynI332AfVEsUSMIFl9UPaJB9bWPmmENEdAxfGRi
2Sb7It5oLHiPRCWXIdCnKZ4t2exlp2j7tySayWSdUNxvbQzLVcfkM1EQCINCyh9j
yYxT7bPV3NTCXbY8qTGhw6xHCt8/pwho+ovisR+LLWI4scL15rZ7J/9VZ1VJBYY=
=xECD
-----END PGP SIGNATURE-----

 

[Vinay Sajip]

I'm writing a custom logging Handler that sends emails through AWS Simple
Email Service using the boto library.
As there's a quota cap on how many (200) emails I can send within 24hrs, I
think I need to buffer my log messages from the emit() calls (Or is that a bad
idea?).
And I was reading the Handler documentation and was confused if I should call
the acquire() and release() methods from within a flush() call.
--
Fayaz Yusuf Khan
Cloud developer and architect
Dexetra SS, Bangalore, India
fayaz.yusuf.khan_AT_gmail_DOT_com
fayaz_AT_dexetra_DOT_com
+91-9746-830-823

 signature.asc
< 1KViewDownload

If you are using SMTPHandler, calling flush() won't do anything.
You'll probably need to subclass the handler to implement rate
limiting.

In the stdlib, only StreamHandler and its subclasses actually
implement flush(), which flushes I/O buffers to disk.

Regards,

Vinay Sajip

 

[Vinay Sajip]

Anyway, I read the source and found many interesting things that ought tobe
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

 

[Vinay Sajip]

Well, as emit() is always being called from within a lock, I assumed that
flush() should/would also be handled similarly. Afterall, they are handling the
same underlying output stream or in case of the BufferingHandler share the same
buffer. Shouldn't the access be synchronized?

Yes, you might well be right - though no problems have been reported,
it's probably best to be safe.

Regards,

Vinay Sajip

 

[Vinay Sajip]

buffer. Shouldn't the access be synchronized?

I've now updated the repos for 2.7, 3.2 and default to add locking for
flush/close operations. Thanks for the suggestion.

Regards,


Vinay Sajip