adding keyword

Extension manager can deadlock

Many functions of the extension manager service take a XCommandEnvironment
argument. It is used to obtain a XInteractionHandler of which the function
handle is called if necessary. XInteractionHandler::handle is provided by the
caller of the extension manager function. handle  may not only be called from
the extension manager itself but also from other APIs to which the
XCommandEnvironment is passed. This is done, for example, when calling ucb
functions.

XInteractionHandler::handle can show dialogs, which require the solar mutex to
be locked. In many cases the thread that calls the handle function has already
acquired the extension manager mutex, so that this thread owns both mutexes. If
at this point another thread calls an extension manager function then it will
block when trying to acquire the extension manager mutex. It will only continue
if the first thread has completed the interaction and has eventually released
the extension manager mutex.

The problem arises if the second thread already owns the solar mutex before it
acquires the extension manager mutex. It will then be blocked by the extension
manager mutex which is held by the first thread. The first thread cannot acquire
the solar mutex in XExtensionManager::handle which is held by the second thread.

One can get in this situation when both threads already own the mutex which will
be later acquired by the other thread. For example, thread one acquires the
extension manager mutex while thread two acquires the solar mutex. At this
point, everything is fine until thread one (holding the extension manger mutex)
tries to acquire the solar mutex. It will then block and will therefore not
release the extension manager mutex. So whenever thread two (holding the solar
mutex) calls an extension manager function which acquires the extension manager
mutex then it will also block, because it it is held by thread one.

The usual solution would be to make sure that both threads acquire the the
mutexes in the same order. That is the extension manager could acquire the solar
mutex before acquiring its own mutex. However, the solar mutex is not a usual
mutex, because it may be released at different points in code. This may be OK
for VCL but makes it unusable for all other parts of the code. In the current
case this caused the deadlock: A worker thread is adding an extension and
acquires the extension manager mutex. The extension manager calls
XInteractionHanlder::handle, which acquires the solar mutex and then shows a
dialog by calling Execute. Execute releases the solar mutex and allows the main
thread to dispatch events. This triggered a vcl timer running in the main
thread. This thread owns the solar mutex and calls a function of the extension
manager. This function blocks because the extension manager mutex is held by the
worker thread. The Dialog.Execute function will then  acquire again the solar
mutex, which is not possible because it is being held by the blocked main
thread. As a result, the worker thread blocks as well and  cannot release the
extension manager mutex which is needed by the main thread. 

To solve the problem I rearranged the code of XExtensionManager::addExtension so
that the extension manager mutex is never acquired when
XInteractionHanlder::handle is called.

@jsk: Please test extensively the adding of extensions. To simulate the "double
click on the icon" scenario one can start soffice providing the path to an
extension. For example:
soffice d:\dict-en.oxt

Please test also installing extension with licenses, different version,
unfulfilled dependencies. Go through the different control flow paths. That is,
also click the cancel buttons in the dialogs.

Adding me to CC

Unopkg cannot be  tested automatically, so there won't be any in depth testing
here, doing some selected scenarios only. The rest is praying.

Linux: Installation basically works, though the mime-handler in GNOME grabs the
.oxt file type and opens it as archive. However, when using "open with" we can
select the office (e.g. Writer) and install the extension. Linux is good then.

Tried installing additional extension on Windows XP using double click appears
to work as well, even though - for some reason - OOo is only "recommended" as
option but not the default association. Running a number of additional tests.

Ok, retried with full system integration using the switch provied in the CWS
description. 
Extensions install on doubleclick and via command line (unopkg) and soffice.exe.
However, this process is really slow. Apparently we have lost a lot of
performance in this area. Installing multiple extensions slows the office start
down significantly. From a performance point of view this is hardly tolerable.
However, the issue is fixed as all supported installation modes work without any
deadlock.