[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId, XVisualIDFromVisual on Linux
From:       Sergey Bylokhov <serb () openjdk ! java ! net>
Date:       2022-01-24 18:49:10
Message-ID: CqV7x2bv242l3Nh8jx1RwmVTP0rKFyI6xrZWVoA1KUg=.c1b991c1-1ea3-4acd-b41e-1a82931a6533 () github ! com
[Download RAW message or body]

On Mon, 24 Jan 2022 07:49:30 GMT, Maxim Kartashev <duke@openjdk.java.net> wrote:

> Can you elaborate, please? Do you mean that this custom JDK would synthetically \
> change `X11GraphicsDevice.screen` at the "right" time?

Yes, at the "right" time and the "right" number of monitors.

> > I am not sure that it is possible to synchronize access to the screen number \
> > across the code w/o introducing deadlocks, the current change does not cover all \
> > cases where the X11GraphicsDevice.screen is passed around. probably we should \
> > follow this [suggestion](https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b \
> > 599f942437cd805cad1/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L58) \
> > and everywhere the "screen" is used under the awt lock (1)check that it is less \
> > than the number of screens and use 0(main screen as a fallback), or (2) some \
> > "default value" if the number of screens is zero at that time - something similar \
> > was implemented on macOS by the \
> > [JDK-8211992](http://hg.openjdk.java.net/jdk/jdk/rev/814c49afb1a7)
> 
> I agree, returning some default as a fallback should also work. However, that's so \
> radically different from the approach I've taken that a separate PR would be \
> required.

It is better to start from the bug reproducing. As the change - the awt lock always \
should be the last one, I am not sure that wrapping a bunch of code by that lock is \
safe.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7182


[prev in list] [next in list] [prev in thread] [next in thread]