juanpablo-santos commented on PR #307:
URL: https://github.com/apache/jspwiki/pull/307#issuecomment-1752606848
Hi @arturobernalg !
> However, this approach has limitations when it comes to working with
condition variables and allowing for custom scenarios. Specifically, using a
utility class for locking would make it challenging to implement more complex
control flows that involve waiting for certain conditions to be met or
signaling other threads to proceed.
>
> In essence, while the utility class would make the code cleaner for basic
locking and unlocking, it might not be flexible enough to handle advanced
locking scenarios that require the use of conditions.
I agree that more complex scenarios would fit inside this utility class.
However, the scope of the PR is to switch away from `synchronized` blocks, and
for all them we have the same idiom all over the place:
```
lock.lock();
try {
doSomething();
} finally {
lock.unlock();
}
```
So abstracting it into a common method makes sense to me. If later on a we
want to refactor or we want to capture more complex scenarios, we can move away
from the utility `synchronize` method. The utility/class method focus should be
more about synchronizing than locking (hence the names).
WDYT?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jspwiki.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
