Apache OpenOffice (AOO) Bugzilla – Issue 92756
Opening the link to more extensions (extension-manager) takes too long
Last modified: 2013-08-07 15:31:14 UTC
Description by TZ: Since some builds open a link from SO9/OOo3 takes a long time and also the Office freezes for some time. This isn't in SO8 U11/OOo 2.4.1. The link opened immediately and the office doesn't freeze for this time. How can this be reproduced and compared between the 2 versions : - open the extension manager (Tools/Extensios Manager ...) - click on the link "get more extensions here ..." - OOo 3.0/SO9.0 (build OOo300m2) => 35 seconds (until Extension-Site is open in Mozilla and until this the Extension Manager and the Office aren't responding) - OOo 2.4.1/SO8 U11 => 1-2 sec (the page opened immediately and the Office is responding in this time frame) (checked on my Notebook and Mozilla was started) I saw the same behavior of OOo3.0 on SunRay. And it exists with all Links from StartCenter too. So it is a general problem with Links in SO/OOo. TM: Problem is reproducible in a m2 on Windows. It works well (approx 5 sec.) on a Mac. TM->JL: KSO decided that you should take care of this issue as long as DV is not in the office.
.
I changed the OS to Windows only. I couldn't reproduce it on Solaris anymore and as I heard technically, this could be a Windows problem only.
Hennes and Jochen contacted me, as the Uno thread_affine environment is involved in this. As recognized by Thorsten, this is a Windows only issue. The problem according to Hennes is the following scenario: - A mouse click event triggers some function, which wants to open a browser. - The function calls on an Uno object responsible for calling Win32 ShellExecute, which in turn may call COM shell extensions (see http://msdn.microsoft.com/en-us/library/bb762153(VS.85).aspx). - By now, the main thread stops on the affine environments condition, waiting for the affine envs thread to return. - Unfortunately it seems, that the COM service triggered by ShellExecute wants itself to contact an object belonging to the main thread, which currently does _not_ dispatch any messages. This is a typical windows disaster scenario as it happens all the time :-( Some solutions coming directly into my mind: - Fire and forget: Create a new thread making the call to the Uno object ... - Exchange the condition in the affine env. to dispatch messages as well. - Do this directly in the affine env implementation. - Do this in SALs condition implementation. I continue investigating ...
Hint: The question is, why does contacting a particular COM object (indirectly from ShellExecute) does require a define thread to dispatch messages?
added md to cc
This is because some COM object instances (f.e. desktop namespace root obtained by SHGetDesktopObject()) are held as a singleton by COM. Though these ojects can only be used directly from the thread that instantiated them first because the implementation of these objects is not guaranteed to be thread aware. This is reflected by the (undocumented fact) that most of shell or UI related Windows API function can only be called from a STA. Marshalling between apartments is done by a SendMessage call to the threads message queque that instatiated the COM object. Threads that instantiate COM objects must at least have one Window with a Windowproc so that the Sendmessage mechanism works. This thread must never be blocked. A fix can be done in SAL with MsgWaitForMultipleObject if only SendMessage calls are processed while waiting for a synchronization object.
Adding to CWS jl110. Waiting for sync objects no wakes up to dispatch COM synchronization SendMessage calls.
Fixed on CWS jl110
Reassigned for verification
Verified for Windows and Linux.
verified in 3.0rc1 on Linux
Opening links from extension manager, writer and calc works ok in OOO300m6. <1 sec. on Linux (native hardware) ~6 sec. on Windows (VM) Closing
"Waiting for sync objects no[w] wakes up to dispatch COM synchronization SendMessage calls." [see <#desc8>] causes problems elsewhere, see <http://framework.openoffice.org/servlets/ReadMsg?list=dev&msgNo=1829>. It appears that the suggestion to "Exchange the condition in the affine env. to dispatch messages as well. [...] Do this in SALs condition implementation." [see <#desc4>] was not good.
move from past to future target.
Changes target to 3.x. Perhaps sometime a fix will be possible. :-)