(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
