cstamas commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-818693664
> I understand this now, but am not happy with for the following reasons: We have a hard requirement on reentrancy, it is up to the lock to implement that properly. If some lock does not support it, you can employ your history for that (granted), but why impose it on locks which support it out of the box? Java's locks do perfectly fine, so does Redisson. I ran Redisson builds hundreds of times and the overhead was very little. I don't see a reason to impose another layer of emulation if the underlying lock just can be used passthrough. In fact, this can even cause bugs/weird behavior if we don't use the locks as intended. See https://github.com/cstamas/maven-resolver/pull/1 (locally passes test, let's see CI) But in general, I cannot emphasize enough: we use JVM iface ReadWriteLock (that is implemented by both ReentrantReadWriteLock and RedissonReadWriteLock) and that iface **state nothing** about required re-entrant capability of lock implementation. Anytway, the PR above removes questioned bits, pls review -- 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. For queries about this service, please contact Infrastructure at: [email protected]
