Closed ImUrX closed 3 years ago
managed to get a panic https://pastebin.com/FW4rM6Yw
Hmm looks like it's coming from inside wee-alloc? I'm actually not sure if wee-alloc was designed with support for Wasm threads. From a quick glance, it doesn't seem to use atomics or anything here https://github.com/rustwasm/wee_alloc/blob/master/wee_alloc/src/imp_wasm32.rs.
Perhaps try enabling this feature and see what it tells? https://github.com/rustwasm/wee_alloc/blob/master/wee_alloc/Cargo.toml#L24
Or, just disable wee-alloc and see if you still get the issue.
after removing wee_alloc just in case, it works but its 100 times slower than the previous solution, i think this is because of rayon but i never used rayon before Is exploring the whole range of i32 possible numbers too expensive for some reason?
Is exploring the whole range of i32 possible numbers too expensive for some reason?
I mean... it's definitely huge range, especially when combined with random generation (which is slow by itself), but it shouldn't be slower than the serial execution on one thread anyway.
well, thanks for taking your time on reading the code, im gonna try later the wee_alloc feature you recommended and make an issue in there for adding wasm thread support
Np. Sorry couldn't help more.
no no, thank you for helping :P
I tried adding this on my wasm library, i used to make predefined ranges for each thread of the worker and wanted to see how fast wasm threads was compared to the previous method so i tried adding this and it compiles and everything but when executed in the worker, it seems the workers enter some kind of deadlock and stay there consuming cpu. im sorry if this is the wrong place