Closed mschout closed 7 years ago
Micheal, this happens because flopen is non a class subroutine. (see my note about post_rotate()) We can avoid to acquire the lock on LCK file if we already have it. (stored into an instance variable).
Best regards, Emanuele
This is precisely how I fixed it yesterday :)
Sent from my iPhone
On Sep 10, 2017, at 4:36 AM, Emanuele Tomasi notifications@github.com wrote:
Micheal, this happens because flopen is non a class subroutine. (see my note about post_rotate()) We can avoid to acquire the lock on LCK file if we already have it. (stored into an instance variable).
Best regards, Emanuele
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.
I have discovered a deadlock that happens if there is a WARN handler installed that redirects warnings to the log file. What is happening in these deadlocks is that a warning is issued while log_message() is in-flight, which causes another call to log_message(). For example, logging a message with a wide character to a file that does not have :utf8 mode on will cause the actual printing of the log message itself to issue a "Wide character in print" warning. However, if there is a WARN handler installed, that warning is sent to log_message(), which will call safe_flock() on the lockfile. This will never return because the previous call to log_message($string_with_wide_chars) is still holding the lock (at least thats what happens on OSX).
Probably the best thing to do is disable the WARN handler locally during log_message.