[slf4j-dev] [Bug 176] Initialization (getILoggerFactory) is not thread safe

[bugzilla-daemon at qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=176

--- Comment #23 from Simon Arlott <bugzilla.slf4j.simon at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/slf4j-dev/attachments/20130609/02a3e0cf/attachment.html>