I'm concerned about how this might impact logging results. For example, even if the results are written out on a separate thread (and assuming the box has an entirely free processor to deal with it), you can still cause the disk to be busy with I/O during the writes, slowing down the real time of the even thread if it's also doing I/O. Basically, we already have enough problems with reproducible results, so I hate the idea of adding even more non-deterministic behavior to the mix.
On Wed, Feb 23, 2011 at 11:30 AM, <[email protected]> wrote: > Chris, the problem Eric is trying to address here is that you are not > always guaranteed to get the shutdown sequence cleanly when you quit the > app, so this helps insure that data will be written out. > > Although, I'm wondering if 10 seconds is too long, Eric, how about 5 > seconds? > > > > http://gwt-code-reviews.appspot.com/1361801/diff/1/dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java > File > > dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java > (right): > > > http://gwt-code-reviews.appspot.com/1361801/diff/1/dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java#newcode352 > > dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java:352: > public void run() { > Might it be a bit cleaner, to use a java.util.Timer, and have it > periodically call flush()? This way, there's no separation between the > flush mechanism that's there, and this new auto-flush feature. (In > looking at it, might need to make the flushLatch thread conscious, a > separate issue here). > > > http://gwt-code-reviews.appspot.com/1361801/ > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
