Yes, it is. But clearly in a different codebase. Crazy that two teams were using this same esoteric, broken prctl and diagnosing the problem it caused in such short succession.
sweca 3 days ago [-]
Haha, yea. When I was writing this blog post (we had already pushed to production) I came across that post when searching for sources to confirm my findings. Antonio and I were so surprised at the coincidence.
mmh0000 3 days ago [-]
What? The headline does not match the article content at all.
There was no reduced latency. The article title should be something along the line of:
"Bad architecture resulted in a hard-to-troubleshoot bug"
mannyv 3 days ago [-]
I suppose the latency was reduced because the process wasn't being terminated by the kernel anymore.
Really, the title should say "PR_SET_PDEATHSIG doesn't mean what you think it means."
The man page for PR_SET_PDEATHSIG: "The parent-death signal is sent upon subsequent termination of the parent thread and also upon termination of each subreaper process"
mannyv 3 days ago [-]
I was hoping it was something about reducing process latency by using some obscure IOCTL call or switching the scheduler.
Neil44 8 hours ago [-]
I think the latency reduced was the 12 seconds to start playing the video via the ai agent. However I was also expecting some mad kernel microsecond based stuff also.
afdrewq 9 hours ago [-]
[dead]
3 days ago [-]
4 days ago [-]
Rendered at 22:00:03 GMT+0000 (UTC) with Wasmer Edge.
https://news.ycombinator.com/item?id=43153901
There was no reduced latency. The article title should be something along the line of:
"Bad architecture resulted in a hard-to-troubleshoot bug"
Really, the title should say "PR_SET_PDEATHSIG doesn't mean what you think it means."
The man page for PR_SET_PDEATHSIG: "The parent-death signal is sent upon subsequent termination of the parent thread and also upon termination of each subreaper process"