-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Working on reentrant lock migration #133
base: master
Are you sure you want to change the base?
Conversation
head = f.getHead(h); | ||
msg = record != null ? f.format(record) : ""; | ||
tail = f.getTail(h); | ||
} finally { | ||
fLock.unlock(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The synchronized here was just paranoia so that other threads couldn't split the head/format/tail. If the developer did something foolish like:
Handler first = ....
Handler second = ...
second.setFormatter(new CollectorFormatter(null, first.getFormatter(), null));
logger.addHandler(first);
logger.addHandler(second);
I would just eliminate the flock
and if anyone reports a problem we'll just tell them to not let the target formatter escape collectorformatter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't want to make any improvement in this PR rather than migrating to ReentrantLock because, in case I introduce a new bug, it will be more difficult to spot it.
It makes more sense for me to create a new PR with improvements, and then I can try to migrate to ReentrantLock here.
In this way, if there is a bug, we can try to reproduce it with 2 versions to know whether it is caused by ReentrantLock PR or synchronization improvements PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds reasonable. However there is not an equivalent transformation because synchronized(f) is acquiring the lock of 'f'. So if you are going more compatible, the get rid of 'fLock' and check if 'f' is a CollectorFormatter and aquire f.lock.lock()
If it is not a CollectorFormatter, synchronize or don't. No fix for this case because 'f' can be anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think one option would be:
- Remove this.fLock.
- Use a local 'fLock' and assign it f.lock if f is a CollectorFormatter or our lock if not.
- Returning our lock is a minor waste but, keeps the code a little cleaner around lock and unlock.
if (f != null) {
ReentrantLock flock = f instanceof CollectorFormatter
? ((CollectorFormatter) f).lock : lock;
fLock.lock();
try {
head = f.getHead(h);
msg = record != null ? f.format(record) : "";
tail = f.getTail(h);
} finally {
fLock.unlock();
}
} else {
mailhandler/src/main/java/org/eclipse/angus/mail/util/logging/LogManagerProperties.java
Show resolved
Hide resolved
Signed-off-by: Jorge Bescos Gascon <[email protected]>
28e6f9a
to
00db10d
Compare
I am going to wait to see what happens with the synchronized blocks in JDK21+. |
#128