<html>
<head>
<base href="http://bugzilla.slf4j.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Initialization (getILoggerFactory) is not thread safe"
href="http://bugzilla.slf4j.org/show_bug.cgi?id=176#c23">Comment # 23</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Initialization (getILoggerFactory) is not thread safe"
href="http://bugzilla.slf4j.org/show_bug.cgi?id=176">bug 176</a>
from <span class="vcard"><a class="email" href="mailto:bugzilla.slf4j.simon@arlott.org" title="Simon Arlott <bugzilla.slf4j.simon@arlott.org>"> <span class="fn">Simon Arlott</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=176#c20">comment #20</a>)
<span class="quote">> 4. Find a VM independent mechanism for detecting a deadlock that doesn't
> require modifying code outside of the binding.</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>