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

[Steve_Northover@xxxxxxx]

It does cause work procs and timers to run later but they do run eventually
(ie. we don't sleep forever in select() stopping them from running until an
event comes in).  Not great but the best we can do.

Steve

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

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

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

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