Re: [platform-swt-dev] SWT sleep() implementation

[Steve_Northover@xxxxxxx]

Yipes.  100000 us does solve the problem.  Egg on my face ... but the fact that
we need our own locking and sleeping code for X/Xt/Xm is still outrageous.

Note to self - it helps if you actually read the post instead of just blowing up
when someone says the words "sleep" and "X" in the same sentence.

Steve

Steve_Northover@xxxxxxx Sent by: platform-swt-dev-admin@xxxxxxxxxxx 04/23/02 01:45 PM Please respond to platform-swt-dev

To:        platform-swt-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-swt-dev] SWT sleep() implementation

This was part of the changes necessary to fix all of the problems involving XInitThreads. 
It turns out that it is not possible to use this function (or any Xt equivalent) to lock the X libs 
and have any hope of working.  This means that every serious multi-threaded X/Xt/Xm 
app must implement their own locking mechanism or hang randomly.  I am just as amazed 
as you are and ranted loudly and publicly here to this effect a month or two ago. 

If you are implmenting your own lock, you cannot call any X call to sleep, hence the use 
of select().  Believe me, I am the last person in the world that thinks this is a good idea 
but we were force into doing this.  Feel free to submit any other solution that fixes the 
problems and uses Xt calls to sleep but first, do a search of the Eclipse Bugzilla database 
with XInitThreads so what you are up against! 

The problem with upping the timeout value is that XtWorkProcs have no way of waking up 
or sleep mechanism so we can't sleep that long or they will never run. 

Steve

johnrose@xxxxxxxxxxxxxx Sent by: platform-swt-dev-admin@xxxxxxxxxxx 04/23/02 12:38 PM Please respond to platform-swt-dev

To:        platform-swt-dev@xxxxxxxxxxx        cc:                Subject:        [platform-swt-dev] SWT sleep() implementation

Hi -

I have some questions about the SWT implementation of Display.sleep().  Eclipse
on AIX has been observed to burn ridiculous amounts of CPU time (50 - 60%) when
idle.  Java traces have shown that the OS.select() call from Display.sleep() is
responsible for the majority of the CPU time when Eclipse is idle.

The implementation of Display.sleep() was changed in Display.java from version
1.33 to 1.34.  The previous implementation, which uses Xt facilities for
waiting on events, results in no CPU usage on AIX.  Was this change made to fix
a particular bug?  The CVS comment for this change mentions an XInitThreads
problem.

If the select-based sleep implementation is necessary, would it be possible to
increase the timeout value?  Experiments with a timeout value of 100000 us seem
to solve the CPU usage problem, and do not appear to affect responsiveness.

Any thoughts on this would be appreciated.

Thanks-
John

----------------
John Rose
AIX Kernel Development
johnrose@xxxxxxxxxxxxxx

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev