arturobernalg commented on PR #307:
URL: https://github.com/apache/jspwiki/pull/307#issuecomment-1753342760
> 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 **not** 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 we
want to refactor, or we want to capture more complex scenarios, we can always
move away from the utility `synchronize` method. The utility/class method focus
should be more about synchronizing than locking (hence the names).
>
> WDYT?
HI @juanpablo-santos
It makes sense to start with this abstraction for the sake of code
cleanliness and readability.
I'll go ahead and make the changes to incorporate the Synchronizer utility
class. It might take me a couple of days to complete the update, but I'll keep
you posted on the progress.
TY
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
