On 28/04/15 17:46, Peter Levart wrote:
On 04/28/2015 04:57 PM, Daniel Fuchs wrote:
Here's my attempt at simplifying this:
http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.01/
LogManager can be subclassed, and subclasses may override reset() for
different purposes.
So I'm afraid the Cleaner thread still needs to call te public
reset() method. The same unfortunately applies to
readConfiguration().
best regards,
-- daniel
Um, yes of course. This can be fixed:
http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.02/
Hi Peter,
Sorry for the late reply.
My gut feeling is that I dislike multi-state ints.
But I guess that's a matter of taste - so I could probably
overcome it ;-)
What makes me less happy is that I had managed to
remove the explicit synchronized() { } block in the
Cleaner thread - and I now see it's back.
Could we maybe keep the imminentDeath boolean and remove
the explicit locking in the Cleaner thread?
I mean... imminentDeath should be checked from within
the lock - before doing anything. But it does not need
to be set from within a locked section.
best regards,
-- daniel
Regards, Peter
