4 ms·

Threads have some very practical advantages: * Standard, easy way to get a backtrace * Standard, easy way to get a list of active things going on * In many c

Threads have some very practical advantages: * Standard, easy way to get a backtrace * Standard, easy way to get a list of active things going on * In many cases, threads make it easy to follow control flow

chriswarbo 7y ago
Yet threads make backtraces and control flow much less useful, since they miss out important context from concurrent threads. I wouldn't personally say that threads make control flow easier to follow: we might gain a little by disentangling separate activities into threads, but we lose a lot when these get interleaved in arbitrary, non-deterministic ways.
- derefr 7y ago
  > Yet threads make backtraces and control flow much less useful, since they miss out important context from concurrent threads. I mean, when a program panics, you get a stacktrace from (a consistent snapshot of) all the threads, so what's the problem?
  - erik_seaberg 7y ago
    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.
    - derefr 7y ago
      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.
  - gardnerbickford 7y ago
    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.
- white-flame 7y ago
  > Yet threads make backtraces and control flow much less useful, since they miss out important context from concurrent threads. Threads' contexts should be independent from each other. If reading your stack trace relies on the state of other threads, you've got a very brittle design. What is lost is the history of the state the current thread is working with, but the state should be fully encapsulated within the thread, except in the case of large shared read-only input buffers that are being processed in parallel. But those latter buffers aren't hidden from the current thread nor its debugging. Debug information can also be logged on state objects to show its provenance.
  - jrochkind1 7y ago
    > but the state should be fully encapsulated within the thread, except in the case of large shared read-only input buffers Sure. The trick is that the thread design does not ENFORCE that, threads as an abstraction involve shared memory. > If reading your stack trace relies on the state of other threads, you've got a very brittle design. Or a bug. And a bug or a brittle design is exactly when you need a debugger the most, right?
gpderetta 7y ago
Also a way to make use of more than a tiny bit of silicon in that expensive CPU you just bought.

chriswarbo 7y ago

Yet threads make backtraces and control flow much less useful, since they miss out important context from concurrent threads. I wouldn't personally say that threads make control flow easier to follow: we might gain a little by disentangling separate activities into threads, but we lose a lot when these get interleaved in arbitrary, non-deterministic ways.

derefr 7y ago
> Yet threads make backtraces and control flow much less useful, since they miss out important context from concurrent threads. I mean, when a program panics, you get a stacktrace from (a consistent snapshot of) all the threads, so what's the problem?
- erik_seaberg 7y ago
  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.
  - derefr 7y ago
    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.
- gardnerbickford 7y ago
  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.
white-flame 7y ago
> Yet threads make backtraces and control flow much less useful, since they miss out important context from concurrent threads. Threads' contexts should be independent from each other. If reading your stack trace relies on the state of other threads, you've got a very brittle design. What is lost is the history of the state the current thread is working with, but the state should be fully encapsulated within the thread, except in the case of large shared read-only input buffers that are being processed in parallel. But those latter buffers aren't hidden from the current thread nor its debugging. Debug information can also be logged on state objects to show its provenance.
- jrochkind1 7y ago
  > but the state should be fully encapsulated within the thread, except in the case of large shared read-only input buffers Sure. The trick is that the thread design does not ENFORCE that, threads as an abstraction involve shared memory. > If reading your stack trace relies on the state of other threads, you've got a very brittle design. Or a bug. And a bug or a brittle design is exactly when you need a debugger the most, right?

gpderetta 7y ago

Also a way to make use of more than a tiny bit of silicon in that expensive CPU you just bought.