To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=47541
User mmeeks changed the following:
What |Old value |New value
================================================================================
Assigned to|mmeeks |cmc
--------------------------------------------------------------------------------
------- Additional comments from [EMAIL PROTECTED] Fri May 6 07:19:44 -0700
2005 -------
So - I'm guessing this is a combination of threading woes & a (now fixed)
libgnomeui threading problem - that Federico has fixed.
I got Dave to upgrade to our m100 builds; and built a debug enabled library for
him. Unfortunately the non-debugging m100 of ours works - where (apparently) the
m92 one didn't. [ no changes in ooo-build in this area between them, and nothing
relevant up-stream ]. However the up-stream / Sun m100 doesn't work.
So - this has to be either a deep race foo - perhaps helped in our build by our
fix for i#44627# without a working 'condition' life is rather difficult.
Looking for such a thing reveals that the asynceventnotifier.cxx is full of
threading / condition foo and that 'm_bRun' is not correctly guarded by a mutex.
The comment in the startup method there scares me too:
// m_bRun may already be false because of a
// call to stop but the thread did not yet
// terminate so m_hEventNotifierThread is
// yet a valid thread handle that should
// not be overwritten
if (!m_bRun)
Are we really expecting to re-use this thread multiple times & start/shutdown it
in a potentially interleaved fashion: I hope not, the code doesn't look like it
can cope with that.
Anyhow - it seems there is an obvious race between the m_aNotifyCondition.wait()
and the m_aNotifyCondition.reset() that is unnecessary - this patch addresses
that and fiddles with the m_aExitCondition.reset() in a rather futile way to
remove the sense of another race - it should really be guarded by a rather
tedious lock ;-)
Finally - I forget quite why we needed the async thread to do this; I thought we
wanted to post the events to be emitted from the Application:: main loop, but
perhaps I'm mistaken.
Caolan ?
--- fpicker/source/unx/gnome/asynceventnotifier.cxx 18 Jan 2005 13:25:45
-0000 1.3
+++ fpicker/source/unx/gnome/asynceventnotifier.cxx 6 May 2005 14:15:27
-0000
@@ -141,9 +141,9 @@ void SAL_CALL SalGtkAsyncEventNotifier::
osl::ResettableMutexGuard aGuard(m_aMutex);
OSL_PRECOND(m_bRun,"Event notifier does not run!");
- m_bRun = false;
m_aExitCondition.reset();
+ m_bRun = false;
m_aNotifyCondition.set();
@@ -210,6 +211,7 @@ void SAL_CALL SalGtkAsyncEventNotifier::
while (m_bRun)
{
m_aNotifyCondition.wait();
+ m_aNotifyCondition.reset();
while (getEventListSize() > 0)
{
@@ -238,7 +240,6 @@ void SAL_CALL SalGtkAsyncEventNotifier::
}
}
} // while(getEventListSize() > 0)
- m_aNotifyCondition.reset();
} // while(m_bRun)
m_aExitCondition.set();
}
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
