Uh, so having Send bounds in WASM code around anything that might touch the DOM is not a great idea right now. Because JS refs can't be sent, and threads are generally unavailable (so we can't create a threadpool to park them). Things just took an unexpected turn.
-
Show this thread
-
I think the answer is to do an unsafe impl of a Send bound around types that touch the DOM, because threads aren't available anyway, so the Send bound is meaningless in the browser right now anyway. Famous last words, probably.
1 reply 0 retweets 1 likeShow this thread -
Replying to @yoshuawuyts
We ran into this in embedded, and it has started to become a problem with multi core devices, which are only just now starting to become common.
1 reply 0 retweets 1 like -
-
Replying to @yoshuawuyts
Basically building abstractions where sync/send meant something more specific (representing the main vs interrupt split), because we didn't have "threads". Then expanding that definition to be sync or send across cores. May not be directly equivalent, but somewhat similar?
1 reply 0 retweets 2 likes
Ah, I think this is different! In our case we don't have threads in the browser yet, which means we can take the adherence to Send/Sync. Once we have threads tho we should use a parked thread instead to actually implement it correctly.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.