This looks AI-generated and very misleading.... definitely decreases my trust in the linked library, which is unfortunate given that the overall approach seems novel and interesting. The intro starts off by saying SDB is better than rbspy because it doesn't have errors related to data races. But then in the body of the article, it says "Data races may occur if the Ruby VM updates the stack while SDB is reading it", but says that's fine because similar issues occur in other profilers. That sort of trivial contradiction (along with the vague language, overly verbose / repetitive intro and summary, and rando citations (an MIT course lecture??)) feels like the hallmark of a predictive language model with no actual understanding of the code it's explaining.
IainIreland · 1h ago
This doesn't read as AI-generated to me at all.
The prose isn't polished enough to be AI. AI generation is unlikely to produce missing spaces like "...which are not readable to humans.SDB uses eBPF ...", or grammatical inaccuracies like "Ensuring Fully Correctness".
As for the data race thing, it seems to me that there's a pretty clear distinction between rbspy's approach (as described in reference 1) and this blog post. rbspy is walking the native stack, which occasionally fails. SDB seems to be looking at Ruby's internals instead, and has some sort of generation-number design to identify cases where there was a data race.
Beyond that, this post just absolutely sounds like what somebody would write if they were trying to describe in prose why they think their multi-threaded code is correct, especially the "Scanning Stacks without the GVL" section.
The prose isn't polished enough to be AI. AI generation is unlikely to produce missing spaces like "...which are not readable to humans.SDB uses eBPF ...", or grammatical inaccuracies like "Ensuring Fully Correctness".
As for the data race thing, it seems to me that there's a pretty clear distinction between rbspy's approach (as described in reference 1) and this blog post. rbspy is walking the native stack, which occasionally fails. SDB seems to be looking at Ruby's internals instead, and has some sort of generation-number design to identify cases where there was a data race.
Beyond that, this post just absolutely sounds like what somebody would write if they were trying to describe in prose why they think their multi-threaded code is correct, especially the "Scanning Stacks without the GVL" section.