zanmato1984 commented on issue #40069: URL: https://github.com/apache/arrow/issues/40069#issuecomment-1964107779
> @zanmato1984 I'm not sure about the answer to the rest of your question, but for the record Arrow C++ doesn't promise any ABI stability. We do try to maintain API compatibility (with the occasional deprecation or signature change), but people are expected to recompile when switching from one version of Arrow C++ to another. Thank you for the info. After some attempts to draft a fix, I found something worth discussion. First I was able to reproduce the TSAN error using a simple UT. Then I tried to do a plane fix proposed by @pitrou , that is using relaxed atomic stores. Given that I'm not aware of how to apply atomic operations on plane memory in C++, I'll have to change the definition of the scratch space into several atomic variables. However, the interpretation of the scratch space is type-dependent, i.e., some types treat it as two 32-byte space and others treat it as two 64-byte space. This makes "defining the scratch space as a fixed number of atomic variables in the class" not feasible. Now I'm drafting the alternative way, which is using extra atomic flags + spinning (keeping scratch space itself unchanged - as plane memory), which is basically what I talked about in my previous comment. It'll come later. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
