The new pref is "network.dns.resolver-thread-extra-idle-time-seconds"
The default is 60 seconds. This means that threads will stay idle for an extra 60 seconds, after which they are shutdown.
Setting the pref to 0 would preserve the behaviour before the threads were swiched to use nsThreadPool - meaning that they would be shutdown immediately after ThreadFunc completes.
Setting the pref to -1 would keep the threads alive forever.
MozReview-Commit-ID: CoUB5gan4MR
--HG--
extra : rebase_source : 7b444789eebaf43c939ce9d7153218c4cd594b65
Instead of creating and deleteing each thread, we use a nsThreadPool with a max of 8 resolver threads.
Whereas before each thread would run ThreadFunc exactly once then shut down, the threads may now remain active for a while. During this time we may post another task(runnable) to the thread.
MozReview-Commit-ID: FiE370ic1ah
--HG--
extra : rebase_source : 065bbf1f9867dfb38ac7b13816d4d06824d3a05d
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
... when comparing against the native resolver. DNS_TRR_COMPARE is meant
to compare how the actually performed name resolves fare against each
other.
MozReview-Commit-ID: 98NoUGPpHr6
--HG--
extra : rebase_source : 4042c81da3e5478de26feb7f83c98ee5eb298156
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
the id was a b2g feature only settable via chrome privd xhr and is no
longer active in the code base
MozReview-Commit-ID: 84GPNvhvjNb
--HG--
extra : rebase_source : ab5c2229b98e1407b8b74ef2ee00dcfea45e046a
... and before chasing a cname, check if the address record for that
CNAME is actually in fact already provided in the DNS packet that passed
on the CNAME!
Some existing tests ajusted for this. Two new tests added.
MozReview-Commit-ID: CBMO7N7jMEX
--HG--
extra : rebase_source : 1110a8df6d89fcbb0ad2a35b3762b837ce7a1e18
Move the TRR blacklist check to the main thread, and since it is now
done a little later and for each separate request, make sure to only do
the telemetry counting for one of the record types (A) so that we don't
count them twice.
MozReview-Commit-ID: BgvU4TzrpCq
--HG--
extra : rebase_source : 304bc75a6f22963b51e89034de1b30506337b6ec
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
If the confirmation state machine has gone into FAILED mode, updated
prefs is reason enough to try again and possibly get TRR verified
proper.
MozReview-Commit-ID: ALRbNJdvxdn
--HG--
extra : rebase_source : 8ad0a7d74d570228db17d91c1f5127b0524117a8
In a DOH response to a query asking for an A or AAAA record, a CNAME
response is often accompanied by A/AAAA resources as well. With this
change, TRR now rather use those address records than following the
CNAME record. This saves name resolver round-trips.
MozReview-Commit-ID: GcjZj5Ehz68
--HG--
extra : rebase_source : b80d9818cb8fa6139feeeec3d2fb11a5b800ee48
... but keep the logic that avoids re-initialization.
MozReview-Commit-ID: 2XQCRaM6U4B
--HG--
extra : rebase_source : e7291b3c7b26d39dcfde445212dd4f10b63ec98d
It isn't supported server side, so make the TRRoff mode instead count
as nativeonly.
MozReview-Commit-ID: 73si3kam6xU
--HG--
extra : rebase_source : 2869fc515ffb23303bdf2fc5e231d0edc62193e7
