LockManager.handleException errors on shutdown about eclipse.platform.ui

[laeubi]

I think this is a race condition here:

return (!display.isDisposed()) && (display.getThread() == Thread.currentThread());

so actually the disposed check here is a bit useless when we assume multithreading and maybe better a catch clause is used.

Beside that the check in aboutToRelease seems strange as it only clears out if the thread is an UI thread, but this is only true if display.getThread() == Thread.currentThread() so I think this could be simplified to

@Override
public void aboutToRelease() {
  if (ui == Thread.currentThread()) {
	  ui = null;
  }
}

[iloveeclipse]

Sure there is a race condition, but the errors I've reported weren't seen in last ~10 years...

[iloveeclipse]

the check in aboutToRelease seems strange as it only clears out if the thread is an UI thread

This is intentionally, it only allows to release if the UI thread does it.

so I think this could be simplified to

Yes, that can be done. PR?

[iloveeclipse]

My main concern here is less the errors mentioned (which should be for sure fixed), but that workbench shutdown behavior seem to be changed now.

If that is "expected", I would like to understand what exactly caused shutdown behavior change and if there are other possible side effects beside errors here (worst case: workbench or workspace states are not properly persisted etc).

[laeubi]

It might be that a Job is running but the test shuts down faster...

[iloveeclipse]

No, that was my main workspace, not a test. Just a regular shutdown in a workspace that I use every day.

[iloveeclipse]

This error is fixed now, but as expected we see now two other issues, unfortunately lacking stack traces:

• eclipse-platform/eclipse.platform.resources#114
• eclipse-platform/eclipse.platform.runtime#50

I will keep this issue open to see what the stack traces added say.

[iloveeclipse]

Haven't seen that after recent changes, let assume we are fine now.