Stephan Bergmann-2 wrote
I think you should execute your shutdown activies on notifyTermination,
not queryTermination. The latter can be veto'ed by some other listener,
in which case Desktop would cancel the termination and continue running
(and notify you with queryTermination eventually followed by
notifyTermination again later on).
Thank you for your suggestion. Yes, queryTermination should be a place to
set up some status changes. And real stop or shutdown a process should be
done in notifyTermination. BTW, I saw that there is a XTerminationListener2
where cancelTermination() is called when the master environment (e.g.,
desktop) was canceled in it's terminate request. Is it good to use this
interface?
That queryTermination is called with SolarMutex locked is a bug. (Is
notifyTermination also called with SolarMutex locked? Would need to
check, in framework/source/services/desktop.cxx.) However, it might be
a bug not easy to fix without opening any number of pandora's boxes...
Is there a bug report number regarding this issue? I would like to check its
progress in the future. In addition, since notifyTermination is also
protected by SolarMutex, I am wondering if you see any workaround to deal
with such a deadlock issue related to multithread shutdown. Thank you.
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.