Florent Viard added the comment:
Sorry to reply after a so long time.
Please don't close this issue too fast, there is really a big issue that is not
related to my specific case.
(Note that the attached test case is not the real case, but a small piece of
code that is able to reproduce the issue consistently)
Also, I don't pretend that my fix proposal is the solution, but the issue
definitively exists.
To reply to your comment:
<<<
handle() and emit() are high level methods of a handler, and format() is at a
lower level. Not all emit() methods will call format(). For example,
socket-based and queue-based handlers don't. So it is not in general possible
to separate format() out - you will need to have a customised handler to deal
with your somewhat unusual use case, and do whatever you need in there.
>>>
That is not true even if it is a little hidden in the code:
- SocketHandler: emit first calls makePickle that almost starts with
"record.getMessages()" that does the interesting thing.
(self.format mainly does getMessages(), that is the function that gets the
messages arguments, eventually from properties)
- QueueHandler: emit first calls "prepare(record)", that starts by calling
self.format(record).
But after having looked deeper at the code, maybe my fix proposal could be
modified to be something like:
new function in "LogRecord" class:
def stringifyMessage(self):
# CODE THAT WAS IN getMessages()
self.processed_msg = str(self.msg)
if self.args:
self.processed_msg = self.processed_msg % self.args
modify the getMessages function to:
def getMessages(self):
if not self.processed_msg:
self.stringifyMessage()
return self.processed_msg
Then, in the "__init__.py" handle function, add the following before
"self.acquire()":
record.stringifyMessage()
Thus, no need to change anything, any handler, but the "message" arguments will
be processed before getting the lock of "logging".
Regarding the second part of your comment, just saying that "generally"
threading locks are a complex topic, doesn't remove the fact that in this
specific logging case, there is a real bug regarding how python works. Here,
you assume that an user of "logging" is supposed to know how the inside thread
locking of "logging" works because the section under locking of logging leaks
into "user space code". I'm pretty sure that almost everyone using logging
today would not think that such an issue could arise.
I could agree with your point if the problem that was solvable, but i'm pretty
sure that there is at least a solution that is working with backward
compatibility and at worst minor disturbance to some very specific users of
some specific handlers.
----------
resolution: not a bug ->
status: closed -> open
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25668>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
