Data race in reallocate
anuraaga opened this issue · 1 comments
I noticed this data race in Rellocate
in go-re2. It's not using this package yet but I think it would still have the same issue.
https://github.com/wasilibs/go-re2/actions/runs/9343300382/job/25712674994
I think because malloc takes a lock in Wasm, this isn't a real issue and just that the Go race detector isn't aware of wazevo-compiled locks but probably still good to allow the Go race detector to be safe, microoptimization of Grow
shouldn't be too important.
@ncruces Wondering if any thoughts on an implementation, a mutex in LinearMemory
, or just use atomic ops?
Yeah, I would hope a mutex isn't really needed, but it's probably the simplest thing to do.
And since wazero is already doing atomicStoreLengthAndCap
, a mutex around Grow
might be needed; simple atomics might not quiet the race detector. I wouldn't want to spaghettify this with a CAS loop.