michael-o commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-818710284
> > > > 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 [cstamas#1](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. I am not referring to the interfaces, but your are right about the interfaces, of course. See below. > Also, I don't quite understand the "We have a hard requirement on reentrancy", as `NamedLock` implementation are re-entrant. And for sure we do NOT have requirement on underlying constructs to be re-entrant (see semaphore case). Apologies for haven't made it clear enough. This is the reentrancy I am talking about: https://maven.apache.org/resolver/apidocs/org/eclipse/aether/SyncContext.html. This is the hard requirement I am talking about. Which is satisfied with `ReentrantReadWriteLock` and Redisson's Lock. Everything else needs to be simulated internally. Is my position clear now? -- 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: us...@infra.apache.org
