Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firefox panic with parking_lot (Parking not supported on this platform) #1401

Closed
Titaniumtown opened this issue Mar 22, 2022 · 6 comments · Fixed by #1404
Closed

Firefox panic with parking_lot (Parking not supported on this platform) #1401

Titaniumtown opened this issue Mar 22, 2022 · 6 comments · Fixed by #1404
Labels
bug Something is broken

Comments

@Titaniumtown
Copy link
Contributor

Describe the bug
With the latest egui commit, egui randomly fails with the error "Parking not supported on this platform" in relation to parking_lot.

To Reproduce
Steps to reproduce the behavior:

  1. Browse to egui site using latest commit of egui with Firefox browser
  2. Interact with site for a bit
  3. Observe panic in browser console

Expected behavior
The site should run fine on Firefox

Screenshots
image

Desktop (please complete the following information):

  • OS: Arch Linux
  • Browser: Firefox
  • Version: 100 (nightly)
@Titaniumtown Titaniumtown added the bug Something is broken label Mar 22, 2022
@emilk
Copy link
Owner

emilk commented Mar 22, 2022

As "DusterTheFirst" remarked on the egui Discord, this seems to be related to parking_lot relying on atomics which are not enabled on webkitgtk by default:

https://github.com/Amanieu/parking_lot/blob/1cf12744d097233316afa6c8b7d37389e4211756/core/src/thread_parker/wasm.rs#L8-L9
https://github.com/Amanieu/parking_lot/blob/1cf12744d097233316afa6c8b7d37389e4211756/core/src/thread_parker/mod.rs#L69-L79

I don't know why ThreadParker is being used though.

I don't understand how ThreadParker is even a thing in wasm32 - there are no threads in wasm (yet).

I don't know if this should be opened as an issue in parking_lot and/or if we should change epaint::mutex to always use atomic_refcell instead of parking_lot when compiling for wasm32.

@Titaniumtown
Copy link
Contributor Author

Titaniumtown commented Mar 22, 2022

relying on atomics which are not enabled on webkitgtk by default:

This is on firefox though.

@emilk
Copy link
Owner

emilk commented Mar 22, 2022

It's a bit dissapointing (and surprising) that you don't get a proper Rust callstack in the console - or did you accidentally crop that from the image?

@emilk
Copy link
Owner

emilk commented Mar 22, 2022

Ok, then I'll just revert to using atomic_refcell on wasm targets and it should be all good again. Until we use a 3rd party library that uses parking_lot

@emilk
Copy link
Owner

emilk commented Mar 22, 2022

Please try out #1404 @Titaniumtown

@imxood
Copy link

imxood commented Mar 22, 2022

Using latest code, and this is Ok,
OS: Deepin Linux
Browser: Firefox
image

emilk added a commit that referenced this issue Aug 11, 2023
Replace `atomic_refcell` with `parking_lot` on wasm32.

`parking_lot` has had problems running on wasm32 before
(#1401)
but it works these days.
If we have problems again we can always switch to `std::sync::Mutex`.

Closes #3102
emilk added a commit that referenced this issue Aug 11, 2023
Replace `atomic_refcell` with `parking_lot` on wasm32.

`parking_lot` has had problems running on wasm32 before
(#1401)
but it works these days.
If we have problems again we can always switch to `std::sync::Mutex`.

Closes #3102
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is broken
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants