JDK-8297962 review ?

[Laurent Bourgès]

Hi,

My main concerns consists in avoiding any deadlock due to appkit (main
thread), EDT, flusher & disposer + user threads...

Instead of new lock.wait(), why not rely on other existing patterns like
LWCToolkit.invokeAndWait() ?
It implements non-blocking rendez-vous to avoid appkit or EDT threads to
wait but perform other pending events meanwhile.

More details later,
Laurent

Le mar. 28 janv. 2025, 21:19, Stanimir Stamenkov <stanio at yahoo.com> a
écrit :

> Tue, 28 Jan 2025 11:32:41 -0800, /Philip Race/:
>
> > why would the state change never happens / gets lost ?
>
> Is it possible the state changes after the 'if', and before the lock is
> obtained?
>
>          if (peer.getState() != state) {
>              synchronized (lock) {
>
> Maybe the the 'if' test should be re-evaluated inside the synchronized
> block, first or maybe using a CountDownLatch is more suitable:
>
>          CountDownLatch latch = new CountDownLatch(1);
>          WindowStateListener wsl = new WindowStateListener() {
>              public void windowStateChanged(WindowEvent e) {
>                  if (e.getNewState() == state) {
>                      latch.countDown();
>                  }
>              }
>          };
>
>          target.addWindowStateListener(wsl);
>          for (int retries = 5; retries > 0
>                  && peer.getState() != state; retries--) {
>              try {
>                  latch.await(1, TimeUnit.SECONDS);
>              } catch (InterruptedException ie) {
>                  Thread.currentThread().interrupt();
>                  break;
>              }
>          }
>          target.removeWindowStateListener(wsl);
>
> > The code wants a specific state (NORMAL). What if the window is
> > transitioned to some other state instead ?
> > So there's a couple of possibilities.
>
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250129/d1098f6f/attachment.htm>