http://bugzilla.slf4j.org/show_bug.cgi?id=176
--- Comment #23 from Simon Arlott <[email protected]> --- (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.
_______________________________________________ slf4j-dev mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-dev
