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 <sta...@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.
>
> --
>
