Make in-process implementation threadsafe. #89
Conversation
|
Tested locally by forcing the in-process implementation to be used in a mac build of Servo. |
|
@jdm Would it be useful to add an |
|
Maybe, but then I expect we would need to modify a lot of Cargo.toml files to make use of it. |
|
@bors-servo r+ |
|
📌 Commit 30b2024 has been approved by |
Make in-process implementation threadsafe.
|
☀️ Test successful - status-appveyor, travis |
|
I agree that the Note that in the Mach ( (The |
|
If it's possible to remove the bits that make it Sync then we should. |
|
@nox a feature to force use of the Note that this will require some adaptations to the test suite too, as presently some tests make assumptions about the backend in use based on what system we are on. |
Wrap the inprocess receiver in a simple `RefCell<>` instead of `Arc<Mutex<>>` (again). Adding the mutex here is not a good idea: it only adds overhead and potential errors, since not all of the other backends have a `Sync` receiver either; nor does the `mpsc` mechanism `ipc-channel` is modelled after. In fact it fundamentally violates the "single receiver" aspect of `mpsc`, as outlined in servo#89 (comment) Users can still wrap it explicitly if they need to, and know it doesn't introduce incorrect behaviour in the specific use case. This change mostly reverts the `Receiver` part of 30b2024 ; it doesn't re-introduce the explicit `Sync` declaration for `Receiver` though, as that was/is clearly not true without the Mutex -- nor really desirable, as explained above. This change also doesn't touch the `Sender` part, which is a different story.
inprocess: Don't wrap `OsIpcReceiver` to make it `Sync` Wrap the inprocess receiver in a simple `RefCell<>` instead of `Arc<Mutex<>>` (again). Adding the mutex here is not a good idea: it only adds overhead and potential errors, since not all of the other backends have a `Sync` receiver either; nor does the `mpsc` mechanism `ipc-channel` is modelled after. In fact it fundamentally violates the "single receiver" aspect of `mpsc`, as outlined in #89 (comment) Users can still wrap it explicitly if they need to, and know it doesn't introduce incorrect behaviour in the specific use case. This change mostly reverts the `Receiver` part of 30b2024 ; it doesn't re-introduce the explicit `Sync` declaration for `Receiver` though, as that was/is clearly not true without the Mutex -- nor really desirable, as explained above. This change also doesn't touch the `Sender` part, which is a different story.
No description provided.