Re:Threads Are a Bad Idea for Most Purposes (1995) [pdf]
by erik_seaberg on Tuesday January 28, 2020 @12:37PM
(#22171707)
If a highly concurrent service gets a query'o'death, it's hard to tell which threads were working on it and which were merely within the blast radius. Frameworks tend to roll their own notion of "request context" without it being strongly typed or pervasive across the language and libraries.
Re:Threads Are a Bad Idea for Most Purposes (1995) [pdf]
by derefr on Tuesday January 28, 2020 @06:56PM
(#22175556)
Now I’m curious what backtraces from Postgres look like when parallel scans are enabled. IIRC, you’ve got one isolated fork(2)ed master for the connection, which then has threads to divide work. Not too bad to debug.
Re:Threads Are a Bad Idea for Most Purposes (1995) [pdf]
by gardnerbickford on Tuesday January 28, 2020 @12:38PM
(#22171733)
A snapshot doesn't show the shared memory changes that may have caused the panic. There needs to be a synchronous log of all changes to shared memory to debug an issue.
Similar to having a snapshot of network traffic vs a recording of network traffic.
I mean, when a program panics, you get a stacktrace from (a consistent snapshot of) all the threads, so what's the problem?