Tagging legitimate main thread I/O
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? Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tagging legitimate main thread I/O
(2014/02/08 0:31), David Rajchenbach-Teller 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?
Cheers,
David
Is this topic related to the following warning in TB test log, which has
popped up recently, and is printed by the code quoted below?
(I am bothered by the seemingly very serious nature of the problem in
the comment in the code.)
From my local test run:
Message:
[10549] WARNING: Security network blocking I/O on Main Thread: file
/REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp,
line 422
Routine in ssl/src/nsNSSCallbacks.cpp:
if (running_on_main_thread)
{
// The result of running this on the main thread
// is a series of small timeouts mixed with spinning the
// event loop - this is always dangerous as there is so much main
// thread code that does not expect to be called re-entrantly. Your
// app really shouldn't do that.
=*=> NS_WARNING("Security network blocking I/O on Main Thread");
// let's process events quickly
wait_interval = PR_MicrosecondsToInterval(50);
}
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Tagging legitimate main thread I/O
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 wrote: > > On Feb 7, 2014, at 10:31 AM, David Rajchenbach-Teller > 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
Re: Tagging legitimate main thread I/O
On 02/07/14 10:31, ISHIKAWA, Chiaki wrote: > Message: > [10549] WARNING: Security network blocking I/O on Main Thread: file > /REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp, > line 422 This generally happens when javascript calls a function on an nsIX509Cert that attempts to verify it synchronously. If the certificate has an OCSP uri, network IO will block the main thread. For instance, AddonUpdateChecker.jsm calls CertUtils.checkCert, which traverses the peer's certificate chain (in an inefficient way, but that's beside the point). Getting a certificate's chain causes a verification to happen, which often results in network IO. This is in part due to the legacy certificate verification library we're currently hard at work replacing. In short, this is not legitimate main thread IO, but it's being fixed. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
"Content Security" module proposal
Hello platform! I've sent a proposal to governance [0] to create a new module for content security policies like Content Security Policy (CSP), the Mixed Content Blocker, and Safe Browsing. Please comment on that thread if you have questions or concerns. [0] https://groups.google.com/forum/#!topic/mozilla.governance/lgKybgNES6k ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tagging legitimate main thread I/O
On Feb 7, 2014, at 10:31 AM, David Rajchenbach-Teller 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
DXR UI refresh is live!
https://blog.mozilla.org/webdev/2014/02/07/dxr-gets-a-huge-ui-refresh/ Happy hacking! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DXR UI refresh is live!
that's pretty, but where did the list of classes & class members go when viewing files like http://dxr.mozilla.org/mozilla-central/source/modules/libjar/nsZipArchive.cpp - Original Message - > From: "Erik Rose" > To: dev-platform@lists.mozilla.org, dev-static-analy...@lists.mozilla.org > Sent: Friday, February 7, 2014 1:26:19 PM > Subject: DXR UI refresh is live! > > https://blog.mozilla.org/webdev/2014/02/07/dxr-gets-a-huge-ui-refresh/ > > Happy hacking! > ___ > dev-static-analysis mailing list > dev-static-analy...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-static-analysis > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Rendering meeting, Monday 2:30pm PDT ("the earlier time")
The Rendering meeting is about all things Gfx, Image, Layout, and Media. It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm PDT. The next meeting will take place on Monday, Feb 10 at 2:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2014-February-10#Agenda San Francisco - Monday, 2:30pm Winnipeg - Monday, 4:30pm Toronto - Monday, 5:30pm GMT/UTC - Monday, 22:30 Paris - Monday, 11:30pm Taipei - Tuesday, 6:30am Brisbane - Tuesday, 8:30am Auckland - Tuesday, 11:30am http://arewemeetingyet.com/Toronto/2014-02-10/17:30/Rendering%20Meeting Video conferencing: Vidyo room Graphics (9366) https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2 Phone conferencing: +1 650 903 0800 x92 Conf# 99366 +1 416 848 3114 x92 Conf# 99366 +1 800 707 2533 (pin 369) Conf# 99366 -- - Milan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DXR UI refresh is live!
> that's pretty, but where did the list of classes & class members go when > viewing files like > http://dxr.mozilla.org/mozilla-central/source/modules/libjar/nsZipArchive.cpp Coming back soon: https://bugzilla.mozilla.org/show_bug.cgi?id=965659. We're having some trouble reducing it to a test case smaller than moz-central. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tagging legitimate main thread I/O
(2014/02/08 4:13), David Keeler wrote: On 02/07/14 10:31, ISHIKAWA, Chiaki wrote: Message: [10549] WARNING: Security network blocking I/O on Main Thread: file /REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp, line 422 This generally happens when javascript calls a function on an nsIX509Cert that attempts to verify it synchronously. If the certificate has an OCSP uri, network IO will block the main thread. For instance, AddonUpdateChecker.jsm calls CertUtils.checkCert, which traverses the peer's certificate chain (in an inefficient way, but that's beside the point). Getting a certificate's chain causes a verification to happen, which often results in network IO. This is in part due to the legacy certificate verification library we're currently hard at work replacing. In short, this is not legitimate main thread IO, but it's being fixed. Thank you for the explanation. I can certainly understand that using a third-party library certain can cause this type of issue, the mismatch of the assumed architecture of the application: in this case, the way threads are being used with regard to I/O, network I/O, etc. etc. It is re-assuring to learn that someone is working on to fix this issue. Chiaki Ishikawa ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tagging legitimate main thread I/O
On Fri, Feb 7, 2014 at 11:13 AM, David Keeler wrote: > On 02/07/14 10:31, ISHIKAWA, Chiaki wrote: >> Message: >> [10549] WARNING: Security network blocking I/O on Main Thread: file >> /REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp, >> line 422 David's explanation is mostly correct for Firefox (but see below). However, for Thunderbird that warning occurs because Thunderbird is blocking the main thread waiting for network I/O (and disk I/O). Thunderbird should be fixed so that it stops doing network I/O on the main thread. Then this warning will go away. > AddonUpdateChecker.jsm calls CertUtils.checkCert, which traverses the > peer's certificate chain (in an inefficient way, but that's beside the > point). Getting a certificate's chain causes a verification to happen, > which often results in network IO. This is in part due to the legacy > certificate verification library we're currently hard at work replacing. Even after insanity::pkix lands, it won't be OK to do certificate verification on the main thread because OCSP requests would result in the main thread blocking on network I/O. There is a bug tracking the removal of main-thread certificate verification: https://bugzilla.mozilla.org/show_bug.cgi?id=775698. Cheers, Brian On Fri, Feb 7, 2014 at 11:13 AM, David Keeler wrote: > On 02/07/14 10:31, ISHIKAWA, Chiaki wrote: >> Message: >> [10549] WARNING: Security network blocking I/O on Main Thread: file >> /REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp, >> line 422 > > This generally happens when javascript calls a function on an > nsIX509Cert that attempts to verify it synchronously. If the certificate > has an OCSP uri, network IO will block the main thread. For instance, > AddonUpdateChecker.jsm calls CertUtils.checkCert, which traverses the > peer's certificate chain (in an inefficient way, but that's beside the > point). Getting a certificate's chain causes a verification to happen, > which often results in network IO. This is in part due to the legacy > certificate verification library we're currently hard at work replacing. > In short, this is not legitimate main thread IO, but it's being fixed. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing support for OS/2
On 8/7/13, 1:00 PM, d...@dmik.org wrote: пятница, 2 августа 2013 г., 3:13:23 UTC+4 пользователь Gregory Szorc написал: Are there any objections to this proposal? Hello everybody, I'm the person who's being actively working now on getting Mozilla build on OS/2 again with all the new IPC stuff in. As Peter said, at the present time we have no plans to push our patches but that's only because from my experience this process is very complex and we have very limited resources for working on that task (no surprise). So our idea is to get it all working again first, then create a smaller number of bigger (and logically consistent) patches and try to push them upstream — while still continuing development in our own repo so that we don't depend on how fast the patches are accepted etc. If anybody has a better idea, we are ready to consider it. What about switching the build system, it's not our primary task of course but it will be done sooner or later — this is all to have a more robust build environment and thus save some resources here too. An ideal solution for us in the future would be to put the build files of the new build system (Makefile.kmk, generally one per each subdir) upstream but I'm not sure if it will ever be accepted — this is another reason why we decided to stick to our own repo for the time being. In either case, removing OS/2 support from the existing makefiles - may be done (but better after we completely move away to kBuild). Regarding the main subject. There are many OS/2 parts that are still valid (e.g. the NSPR code) so if you will drop them we will have to reapply them back in our repo. And if we push it back later you will have to reapply them again. This doesn't make sense to me — if you are going to accept our patches at some later stage. If you are certainly not, then you may go on with that. I'm also ready to listen to any other ideas on how we can collaborate in this case. I just realized I never replied to this thread! Given: a) the in-tree OS/2 port hasn't worked in over 2 years b) the OS/2 port is using a "shadow" build system, independent of the official one c) there appears to be little desire to use the official build system for an OS/2 port at this time It's my determination that OS/2 has little use in the Firefox *build system*. (The OS/2 port may wish for some references to remain in C++.) Bug 969757 currently has a patch to remove most remnants of OS/2 from the *entire* tree. If you have any interest in preserving references to OS/2 in the tree, now would be the time to speak up. Gregory ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
