http://bugzilla.slf4j.org/show_bug.cgi?id=176 --- Comment #23 from Simon Arlott <bugzilla.slf4j.simon@arlott.org> --- (In reply to comment #20)
4. Find a VM independent mechanism for detecting a deadlock that doesn't require modifying code outside of the binding.
I suspect this is impossible given that there are conditions that temporarily look like a deadlock but aren't such as tryLock(). You won't really know if it's using a short timeout or an infinite timeout. An obscure locking process could use Thread.sleep() or Thread.yield() while repeatedly checking a condition. I'd suggest allowing it to deadlock and fix all the bindings. Return a TEMP_FACTORY for the simple case involving the same Thread and consider everything else to be a bug in the binding code. If your StaticLoggerBinder could take a long time to initialise then create a background Thread instead of doing it in getSingleton(). For compatibility with existing binding code, increment the API version so that it can return TEMP_FACTORY instead of causing a deadlock. This would be identical to what it does now. -- You are receiving this mail because: You are the assignee for the bug.