With the profiler' IO tracking feature we have a few options: We match certain signatures after the data is collected. + Doesn't require changes to gecko, adjustments are cheap - Matching signatures can be tricky/unreliable
We instrumented gecko to allow IO between two calls + Similar to shutdown write poisoning, more reliable + Can benefit other tools instead of just the profiler - Requires patching gecko to any time we need to adjust this. On Fri, Feb 7, 2014 at 11:23 AM, Jeff Muizelaar <jmuizel...@mozilla.com>wrote: > > On Feb 7, 2014, at 10:31 AM, David Rajchenbach-Teller <dtel...@mozilla.com> > wrote: > > > When we encounter main thread I/O, most of the time, it is something > > that should be rooted out. However, in a few cases (e.g. early during > > startup, late during shutdown), these pieces of I/O should actually be > > left untouched. > > > > Since main thread I/O keeps being added to the tree, for good or bad > > reasons, I believe that we should adopt a convention of tagging > > legitimate main thread I/O. > > > > e.g. : > > - << Reading on the main thread as threads are not up yet >>. > > - << Reading on the main thread as we may need to install XPCOM > > components required before profile-after-change. >> > > - ... > > > > Any thoughts? > > I think this is a good idea. > > Another example of main thread I/O that we don't have a lot of control > over is some of the font reading that happens during rasterization or other > system api's that we call. > > -Jeff > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
