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

[johnrose@xxxxxxxxxxxxxx]

Steve-

Does the 100000 us timeout value not cause the XtWorkProcs problem you
described below?  (Forgive my ignorance on the subject!!).  If this value is
permissible, should I open a bug on this?

Your help is appreciated-
John

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


On Tue, 23 Apr 2002 Steve_Northover@xxxxxxx wrote:

> 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
>
>
>
>