In our plugin we have a timer thread, and also some modal dialogs (which
pop-up automatically in certain conditions, like network disconnects),
that allow one to close or restart the workbench. However, when this
happens (the timer/modal-dialog closing the workbench), it may cause
other modal dialogs underneath (either from our plugin, or native to
Eclipse UI) that were also open, to close themselves and then attempt to
close/restart the workbench *again*. One such example would be:
org.eclipse.update.internal.ui.UpdateUI.requestRestart(boole an) which
calls PlatformUI.getWorkbench().restart() after its dialog exits, even
if due to a workbench shutdown, because disposing the shell of a modal
dialog will make the dialog return the same code as if the OK button had
been pressed.

However, it happens that closing the workbench when it is already closed
is an illegal operation: it our case it throws a NPE and causes UI
mementos to be incorrectly saved. So I'm trying to prevent this problem
from happening, but I'm not finding a satisfactory way to do it.

When we try to close the workbench in our plugin's modal dialogs, we can
just check if the workbench is already closed before trying to close it
again... but that does nothing to prevent this happening in other
plugin's code, including the platform itself.
Another idea would be to add a IWorkbenchListener to veto shutdowns if
the workbench is already closed... but it doesn't work because on the
fisrt close the listeners are cleared and never called afterwards.
The other idea is to use the WorkbenchAdvisor to veto the shutdown, but
it only works if one is running one's own RCP Application (not to
mention it still sounds like a hackish workaround).

So any other ideas? Or are my assumptions wrong and I should be doing
this in a whole different way?