To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=44627
Issue #:|44627
Summary:|Linux/gtk+: Intermittent multi-second delay ...
Component:|gsl
Version:|680m79
Platform:|All
URL:|
OS/Version:|All
Status:|NEW
Status whiteboard:|
Keywords:|
Resolution:|
Issue type:|PATCH
Priority:|P2
Subcomponent:|code
Assigned to:|pl
Reported by:|mmeeks
------- Additional comments from [EMAIL PROTECTED] Wed Mar 9 09:43:25 -0800
2005 -------
Start writer, type rubbish,: hit 'Save', enter a file-name
At this point I get either - a fairly instant response - or ~ 1 time in 3 a
delay of a random duration. When the CPU is loaded:
[ run while true; do echo "foo" > /dev/null; done ] I'm much more likely to get
the delay.
The delay can last forever (in theory), in reality up to 10 seconds is quite
normal ;-)
It seems this is a combination of at least two problems: primarily:
void GtkXLib::Yield( BOOL bWait )
Has turned into a horror, from it's original, rather elegant:
+void GtkXLib::Yield( BOOL bWait )
+{
+ // release YieldMutex (and re-acquire at method end)
+ YieldMutexReleaser aReleaser;
+ g_main_context_iteration( NULL, bWait );
+}
I would badly like to understand why this was necessary - reading the referenced
bugs gives me very little insight.
OTOH - my problem seems to be caused by:
if( bDispatchThread )
{
osl_releaseMutex( m_aDispatchMutex );
osl_setCondition( m_aDispatchCondition ); // trigger non dispatch thread
yields
osl_resetCondition( m_aDispatchCondition );
}
The problem is that 'osl_setCondition' doesn't in fact trigger any threads -
unless - they happen to get scheduled between the 'setCondition' and the
'resetCondition'
This is due to the (rather flakey) implementation of:
osl_waitCondition - which essentially is 1 big loop:
while ( ! pCond->m_State )
{
....
}
Where the pthread_cond_timedwait will return 0 as it is (kindly) broadcasted to
- and then - nip around the loop to notice that the state is (currently) false,
and proceed to do a timeout of another second ;-)
My traces show this happening a good number of times.
I guess - this is also a bug in the implementation of osl_waitCondition - which
has a broken timeout behavior IMHO.
The simple patch at first glance is:
--- vcl/unx/gtk/app/gtkdata.cxx 2 Feb 2005 16:41:15 -0000 1.15
+++ vcl/unx/gtk/app/gtkdata.cxx 9 Mar 2005 17:40:02 -0000
@@ -716,7 +731,6 @@ void GtkXLib::Yield( BOOL bWait )
{
osl_releaseMutex( m_aDispatchMutex );
osl_setCondition( m_aDispatchCondition ); // trigger non dispatch
thread yields
- osl_resetCondition( m_aDispatchCondition );
}
}
Of course - this still doesn't work as it happens; since the condition can
easily still be cleared by another thread entering Yield [ this doesn't fix the
issue for me ].
Not certain what to do here - will give it more thought.
Of course - I'd still love to understand why any of that 1 second timeout stuff
is necessary; if there is really some problem with threads being terminated -
while they are inside the glib mainloop [ which would be rather odd ], can we
not add some goodness to that code to wake the loop up ?
---------------------------------------------------------------------
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]
