Hi Carsten,
Yes, you are right, the possibility of OleInitialize failure is very low.
There wasn't two thread calling DropTarget::initialize, and the calling
thread is not main thread, I just think DropTarget::initialize call should
return already.
But there are another possibility, the freeze main be caused by the main
thread, looks like some recursive calling going on. Could give some
suggestion about this.
BTW: this comes from a crash report.
Thanks
function name: void __cdecl ImplSalYieldMutexAcquireWithWait(void)
function name: long __cdecl ImplHandleSalObjKeyMsg(struct HWND__
*,unsigned int,unsigned int,long)
function name: long __stdcall SalFrameWndProc(struct HWND__ *,unsigned
int,unsigned int,long,int &)
function name: long __stdcall SalFrameWndProcW(struct HWND__ *,unsigned
int,unsigned int,long)
function name: int __cdecl ImplGetMessage(struct tagMSG *,struct HWND__
*,unsigned int,unsigned int)
function name: void __cdecl ImplSalYieldMutexAcquireWithWait(void)
function name: long __cdecl ImplHandleSalObjKeyMsg(struct HWND__
*,unsigned int,unsigned int,long)
function name: long __stdcall SalFrameWndProc(struct HWND__ *,unsigned
int,unsigned int,long,int &)
function name: long __stdcall SalFrameWndProcW(struct HWND__ *,unsigned
int,unsigned int,long)
function name: int __cdecl ImplGetMessage(struct tagMSG *,struct HWND__
*,unsigned int,unsigned int)
function name: void __cdecl ImplSalYieldMutexAcquireWithWait(void)
function name: long __cdecl ImplHandleSalObjKeyMsg(struct HWND__
*,unsigned int,unsigned int,long)
function name: long __stdcall SalFrameWndProc(struct HWND__ *,unsigned
int,unsigned int,long,int &)
function name: long __stdcall SalFrameWndProcW(struct HWND__ *,unsigned
int,unsigned int,long)
function name: int __cdecl ImplGetMessage(struct tagMSG *,struct HWND__
*,unsigned int,unsigned int)
function name: void __cdecl ImplSalYieldMutexAcquireWithWait(void)
function name: public: virtual void __thiscall
WinSalInstance::Yield(bool,bool)
function name: public: static void __cdecl Application::Yield(bool)
function name: public: static void __cdecl Application::Execute(void)
function name: unsigned char __cdecl ImplSVMain(void)
function name: unsigned char __cdecl SVMain(void)
On Mon, Nov 30, 2009 at 3:42 PM, Carsten Driesner
<carsten.dries...@sun.com>wrote:
> Huaidong Qiu wrote:
>
>> \lib\dtrans\source\win32\dnd\target.cxx
>>
>> void SAL_CALL DropTarget::initialize( const Sequence< Any >& aArguments )
>> throw(Exception, RuntimeException)
>> {
>>
>> ...........
>> m_hOleThread= CreateThread( NULL, 0,
>> (LPTHREAD_START_ROUTINE)DndTargetOleSTAFunc,
>> &m_evtThreadReady, 0,
>> &m_threadIdTarget);
>> WaitForSingleObject( m_evtThreadReady, INFINITE);
>>
>> ...........
>> }
>>
>>
>> DWORD WINAPI DndTargetOleSTAFunc(LPVOID pParams)
>> {
>> HRESULT hr= OleInitialize( NULL);
>> if( SUCCEEDED( hr) )
>> {
>> MSG msg;
>> // force the creation of a message queue
>> PeekMessage( &msg, (HWND)NULL, 0, 0, PM_NOREMOVE);
>> // Signal the creator ( DropTarget::initialize) that the thread is
>> // ready to receive messages.
>> SetEvent( *(HANDLE*) pParams);
>> ...........
>> }
>> // no SetEvent( *(HANDLE*) pParams); action this branch.
>> }
>>
>>
>>
>> If OleInitialize() inside DndTargetOleSTAFunc failed,
>> DropTarget::initialize
>> will wait the m_evtThreadReady event forever. Could this cause freezing
>> problem?
>>
>>
> Hi Huaidong,
>
> I must confess that I am not very familiar with the DnD code. If
> DropTarget::initialize is called from the main thread (UI thread) and
> OleInitialize will fail then you are right that this would result in a
> freeze. I checked several hundreds of freeze in OpenOffice.org annd I have
> never seen your scenario. So I would think that theoretically your
> assumption is true but why should OleInitialize fail in this special
> scenario? The thread function calls OleInitialize the first time and doesn't
> change anything. Did you see a freeze in the debugger where you could these
> methods on the stack on two different thread?
>
> Regards,
> Carsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@framework.openoffice.org
> For additional commands, e-mail: dev-h...@framework.openoffice.org
>
>
