Closed
Bug 1509405
Opened 6 years ago
Closed 6 years ago
Open nss in-memory-only on the socket process
Categories
(Core :: Networking, enhancement, P1)
Tracking
()
RESOLVED
INVALID
People
(Reporter: dragana, Assigned: mayhemer)
References
Details
(Whiteboard: [necko-triaged])
No description provided.
Assignee | ||
Updated•6 years ago
|
Blocks: socket-proc-webrtc
Assignee | ||
Updated•6 years ago
|
No longer blocks: socket-proc
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [necko-triaged]
Assignee | ||
Comment 1•6 years ago
|
||
Looks like we don't need to do much here. There is already a code to initialize NSS in content process at [1], the same function will very well work on the socket process as well. Byron, can you please confirm the code at [1] will work for you on the socket process and that there is nothing more needed? Note that with what has landed so far on larch we are not initializing nss on the socket process at all (I believe.) If confirmed, we will likely only have to add `|| XRE_IsSocketProcess()` to the condition at 431 along with bug 1484751 landing. [1] https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp#436 / https://hg.mozilla.org/projects/larch/annotate/11819394462e/media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp#l436
Flags: needinfo?(docfaraday)
Comment 2•6 years ago
|
||
I think that should be fine. We use NSS_NoDB_Init() in a bunch of unit-tests, and those work fine. I do not think we currently have a test-case that uses a real WebrtcProxyChannel in an STS that is initted like this, so that remains a question.
Flags: needinfo?(docfaraday)
Reporter | ||
Comment 3•6 years ago
|
||
Let's do this as a part of WebRTC work. I will close this bug.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
Assignee | ||
Comment 4•6 years ago
|
||
(In reply to Dragana Damjanovic [:dragana] from comment #3) > Let's do this as a part of WebRTC work. I will close this bug. According Byron's comment 2 this more seems like a WORKSFORME. Except the "a real WebrtcProxyChannel in an STS" thing which I don't fully understand and wanted to make it more clear with Byron. Can you elaborate what exactly you mean with "Let's do this as a part of WebRTC work"? That's what this bug was filed for and blocked socket-proc-webrtc. Thanks.
Reporter | ||
Comment 5•6 years ago
|
||
I want to separate what is to be done before WebRTC work and after WebRTC start moving to the socket process. At some point InitNSSInContent in PeerConnectionImpl.cpp needs to be change to turn on nss on the socket process as well (that is why it is not WORKSFORME), but to do that we need to run the webRTC code on the socket process. So this is work that needs to be done during WebRTC move to the socket process and I will leave this to the WebRTC group. About WebrtcProxyChannel, you can ask anyway. I believe that turning on nss needs to be part of concrete WebRTC work, because they know at which point it needs to be turned on.
Assignee | ||
Comment 6•6 years ago
|
||
Got it. Thanks.
You need to log in
before you can comment on or make changes to this bug.
Description
•