[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-core-dev] Build on Windows
|
Hi,
It's kind of the opposite problem, but I would think that you would want
the entire thing throttled by the UI. You can't drop console information so
that says that in the worst case you want to stall the build process
waiting to write to the pipe so that CDT can catch up. I can see this case
having to happen on Win32 because Win32 is so bad about a CPU intensive
process running at the same level as a UI app.
To me that says you want the reading threads to buffer a maximum amount of
unprocessed data and then stop reading to push the stall back into the
build. Any other solution and you have the danger of trying to buffer an
arbitrary amount of data in the jvm and running out of memory. I'd think a
thread pulling out of data reading threads that will only pre-read so much
and then syncExec-ing to the UI thread is probably the right way -- but
perhaps I don't completely grasp the intricacies.
Thanks!
-Chris
At 03:21 PM 2/17/2003 -0500, you wrote:
Yup, that's pretty much exactly what I'm seeing. For small builds with no
errors, I'd prefer to see something while I'm waiting. At 512 characters,
it could be a few files into the build before I see anything.
I can see that if you were asyncExec'ing each line, you'd have problems
since this can end up queing up quite a few Runnables. However, I notice
that there is a syncExec there right now. Did this not solve the problem on
its own? This should theoretically let the pipes fill up while waiting for
the UI to update.
As another solution, I was thinking of using a sync object and making sure
only one Runnable got enqueued at a time. Thoughts?
Doug Schaefer
Senior Staff Software Engineer
Rational - the software development company
Ottawa (Kanata), Ontario, Canada
-----Original Message-----
From: Alain Magloire [mailto:alain@xxxxxxx]
Sent: Monday, February 17, 2003 11:41 AM
To: cdt-core-dev@xxxxxxxxxxx
Subject: Re: [cdt-core-dev] Build on Windows
>
> Hey all,
>
>
>
> Anyone else notice that the C-Build window doesn't get updated until the
end
> of the build on Windows? Is so, anyone working to fix it (I didn't see a
> bugzilla bug on it)?
>
We've notice trying to show in the C-Build every line i.e. calling
Display.asyncExec() has noticeable effect. For long builds, lots of fast
line coming from the builder, the UI thread is overloaded
by the requests and have no time to update anything and on some platform
hangs. Instead the output is flush() at every 512, see
BuildConsoleManager.flush()
So for short builds, you probably will have the impression of a burst
at the end.
Not sure if this is what you are seeing or another bug, note that the
C-Build
has a cap (see preference page).
_______________________________________________
cdt-core-dev mailing list
cdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-core-dev
_______________________________________________
cdt-core-dev mailing list
cdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-core-dev
