Closed jdm closed 5 years ago
There is one hole that I've come up with so far - while the assertion in the Runtime drop implementation catches the point at which a parent runtime is dropped before all of its children are dropped, that only interrupts the thread on which the parent runtime is executing. The threads on which any child runtimes are executing have no signal that their parent runtime is now invalid. The best choice at this point would be to abort the whole program for the sake of safety, but this PR does not do that right now.
I fixed the racing issues by switching to a single mutex around an enum that represents the engine state. This is ready for review.
r? @asajeffrey
@asajeffrey Review comments addressed. I've added more comments around the adjusted refcounting bits to hopefully make clear why it looks weird.
LGTM. Squash and r=me?
@bors-servo r=asajeffrey
:pushpin: Commit 5e3c3ba has been approved by asajeffrey
:hourglass: Testing commit 5e3c3ba644230103b1172f2a3474892d18d95269 with merge 35193f1967c8ed4b4c24fa28587f7577377785a9...
@bors-servo r=asajeffrey
:pushpin: Commit 981e266 has been approved by asajeffrey
:hourglass: Testing commit 981e26650759ebf73cd16393e105b99d64785e10 with merge 7811094fe96f4544e562844fc6bf10053bd10c85...
:sunny: Test successful - checks-travis, status-appveyor Approved by: asajeffrey Pushing 7811094fe96f4544e562844fc6bf10053bd10c85 to master...
The fundamental problem exposed in https://github.com/servo/servo/issues/22342 is that our concept of a parent runtime did not match reality. Using the first JSContext's runtime as the global parent for all subsequent contexts only makes sense if that JSContext outlives every other context. This is not guaranteed, leading to crashes when trying to use those contexts if the first context (and therefore its runtime) was destroyed.
The new design incorporates several changes for safer, more clear context and runtime management:
This change is