we can also turn off the socket process for this tests.

Sorry for the delay.

(In reply to Dragana Damjanovic [:dragana] from comment #1)

Can you give me a short explanation what needs to be done here to make
resetPrefs work with the Socket process that will use gSharedMap.

This is much easier said than done.

So, to be clear, this would not have correctly after child process startup even before shared preferences existed. It would have caused the preferences in the parent process to be reset, but not child processes, which means that parent and child processes would quickly become out of sync.

With shared preferences, the situation becomes a bit harder. There are some ways we could handle this, with varying degrees of brokenness, but all of them require leaking the shared map memory, since any string references which come from it are treated as permanent literals, and are not refcounted.

(In reply to Dragana Damjanovic [:dragana] from comment #2)

we can also turn off the socket process for this tests.

That's probably the best option. Any attempt to support resetting the pref service in a multi-process world is going to require a nontrivial amount of intricate code. And this function is only used by a few highly specific pref service unit tests, and should never be used elsewhere. Since those tests don't depend on the socket process at all (and don't even use the network), there's really no reason we should spend effort trying to make the socket process work with them.

(In reply to Kris Maglione [:kmag] from comment #3)

Sorry for the delay.

(In reply to Dragana Damjanovic [:dragana] from comment #1)

Can you give me a short explanation what needs to be done here to make
resetPrefs work with the Socket process that will use gSharedMap.

This is much easier said than done.

So, to be clear, this would not have correctly after child process startup even before shared preferences existed. It would have caused the preferences in the parent process to be reset, but not child processes, which means that parent and child processes would quickly become out of sync.

With shared preferences, the situation becomes a bit harder. There are some ways we could handle this, with varying degrees of brokenness, but all of them require leaking the shared map memory, since any string references which come from it are treated as permanent literals, and are not refcounted.

(In reply to Dragana Damjanovic [:dragana] from comment #2)

we can also turn off the socket process for this tests.

That's probably the best option. Any attempt to support resetting the pref service in a multi-process world is going to require a nontrivial amount of intricate code. And this function is only used by a few highly specific pref service unit tests, and should never be used elsewhere. Since those tests don't depend on the socket process at all (and don't even use the network), there's really no reason we should spend effort trying to make the socket process work with them.

Thanks!!!

removed blocking on bug 1509472 based on my discussion with Dragana

Junior, can you take this one?
(I will forward you some pointers per email)

Yes.

Since this work is no longer a part of Project Fission, can we remove it from the meta bug?
https://bugzilla.mozilla.org/show_bug.cgi?id=1451850

bug 1546355 eases this work

Not sure why [1] can't get the pref set by test

https://searchfox.org/mozilla-central/rev/227f5329f75bd8b16c6b146a7414598a420260cb/netwerk/base/nsIOService.cpp#408

Well, bug 1555792 disabled socket process for xpcshell tests
https://searchfox.org/mozilla-central/rev/9ae20497229225cb3fa729a787791f424ff8087b/netwerk/base/nsIOService.cpp#410

Comment 11