On Fri, Jan 19, 2024 at 11:08 AM Mark Thomas <ma...@apache.org> wrote: > > > > On 19/01/2024 09:22, Rémy Maucherat wrote: > > On Thu, Jan 18, 2024 at 8:18 PM <ma...@apache.org> wrote: > >> > >> This is an automated email from the ASF dual-hosted git repository. > >> > >> markt pushed a commit to branch 10.1.x > >> in repository https://gitbox.apache.org/repos/asf/tomcat.git > >> > >> > >> The following commit(s) were added to refs/heads/10.1.x by this push: > >> new 67638c17e7 Fix backport of BZ 66508 regression fix > >> 67638c17e7 is described below > >> > >> commit 67638c17e7c19a0280ccafa340183fb179af92f5 > >> Author: Mark Thomas <ma...@apache.org> > >> AuthorDate: Thu Jan 18 18:52:30 2024 +0000 > >> > >> Fix backport of BZ 66508 regression fix > > > > I don't understand the differences introduced. > > In SocketWrapperBase, the lock is not a ReentrantLock, but it still > > cannot be anything else: > > private final Lock lock = new ReentrantLock(); > > > > So couldn't the code be the same as in Tomcat 11 ? (with an extra > > cast, but no need to check anything) > > SocketWrapperBase.getLock() isn't final so it is possible for the > SocketWrapper implementation in a sub-class to override it and use a > different lock type. > > I think ReentrantLock is the only realistic option here but I was aiming > to be extra careful to avoid breakage. We do have some users that > implement custom connectors so I couldn't be sure that a cast wouldn't > break in rare cases.
Oops. silly me, getLock can indeed return whatever. It would be really odd, but it's possible. Sorry for the noise ... Rémy > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
