6 ms·

Many years ago, I submitted a bug report to OpenBSD about an issue I had discovered with threads. I received a one line response from Theo. I still have the mai

Many years ago, I submitted a bug report to OpenBSD about an issue I had discovered with threads. I received a one line response from Theo. I still have the mail. He wrote: "Threads are for idiots." At the time, I felt discounted and I was upset. I was younger then. Today, I realize what he meant and that he's right.

markild 12y ago
> I realize what he meant and that he's right. Could you please expand on this?
- bananas 12y ago
  I think the rise of async/select based and privilege separated designs tend to suggest that threads don't work well for system programming.
  - tptacek 12y ago
    This is an incoherent response. Privilege separation is orthogonal to async designs. It's just as easy to privsep a synchronous program. Meanwhile, while I happen to appreciate async designs, it's far from settled as to whether they're long-term sounder than thread. What I know from experience is that it's easier to make async designs performant. Nothing I've seen suggests that they're that much safer.
    - bananas 12y ago
      Sorry I agree it was rather incoherent - I was distracted half way through posting. I'm not suggesting they are sounder but I'm suggesting that async designs are simpler and simplicity rules when it comes to safety. sync designs tend to evolve into complexity over time to maintain performance (IIS for example which is a behemoth of threaded privsep pain). And in my experience (so totally an anecdote and I accept that), it's not easier to privsep a synchronous program. On top of the IPC concerns of isolation, you still have all the problems associated with threading. It's just pain. (I've written a fair number of both types of systems - none open source unfortunately)
      - tptacek 12y ago
        The original privsep programs weren't async reactor-based designs.
        bananas 12y ago
        No they were single threaded forked. Aware of that.
yp_all 12y ago
Great story. It is good to know that some programmers do learn over time. For every 1 story like yours there are probably 10 where someone is still traying to get "revenge" by saying nasty things about you know who. Those more common stories get replicated through the wires and the end result is that no one cares about programming anymore; they are simply interested in discussing interpersonal relations. Would you rather have your software written by a foolish programmer who is pleasantly tactful or a competent and conservative one who is tactless? The answer of course varies depending on what you are really after.
- JackC 12y ago
  > Would you rather have your software written by a foolish programmer who is pleasantly tactful or a competent and conservative one who is tactless? This is a false dichotomy. Interpersonal skills are among the skills necessary to work on a project that involves more than one person. That covers most of the interesting ones. If there's a successful project with someone who lacks those skills, it's because other people are covering for them -- just like a successful project with a foolish programmer. Sometimes that person makes up for it with other things they bring to the table, and that's fine, but don't pretend a weakness is a virtue.
tptacek 12y ago
This is vintage Theo. It has the virtue of sounding correct, but, because OpenBSD ships threaded libraries, it probably lacks the virtue of being correct. I had a similar experience (note, though: I have a history with Theo, who I know/knew personally). When I was at Arbor Networks, we shipped appliances that monitored ISP backbones that were based on OpenBSD. An analysis process that happened to allocate a lot of memory would occasionally lose a giant chunk of memory. I was able to produce a reduction of the bug and narrow down where in the VM subsystem the bug was happening, but I wasn't able to recommend a fix. Theo's response, to what was clearly a serious bug in OpenBSD, was "I'm not going to look at UVM; it's just Chuck Cranor's thesis project". I lobbied for a switch to FreeBSD, but the monkey.org people that ran the place were dyed-in-the-wool for OpenBSD. :)
- Flow 12y ago
  What happened next? Did the bug get fixed? Did you do a work-around somehow? Don't leave stories unfinished like this :)
  - tptacek 12y ago
    I actually don't know. Arbor could have had its dev team hunt for a fix for the bug, but that would have been silly; no way did it make sense for them to take ownership of a custom fork of the most complicated kernel subsystem. So we worked around the problem instead.
- gypsyharlot 12y ago
  I don't see how his response was unreasonable.
  - tptacek 12y ago
    It helps to understand the role a virtual memory system has in an operating system kernel.
    - fabulist 12y ago

markild 12y ago

> I realize what he meant and that he's right. Could you please expand on this?

bananas 12y ago
I think the rise of async/select based and privilege separated designs tend to suggest that threads don't work well for system programming.
- tptacek 12y ago
  This is an incoherent response. Privilege separation is orthogonal to async designs. It's just as easy to privsep a synchronous program. Meanwhile, while I happen to appreciate async designs, it's far from settled as to whether they're long-term sounder than thread. What I know from experience is that it's easier to make async designs performant. Nothing I've seen suggests that they're that much safer.
  - bananas 12y ago
    Sorry I agree it was rather incoherent - I was distracted half way through posting. I'm not suggesting they are sounder but I'm suggesting that async designs are simpler and simplicity rules when it comes to safety. sync designs tend to evolve into complexity over time to maintain performance (IIS for example which is a behemoth of threaded privsep pain). And in my experience (so totally an anecdote and I accept that), it's not easier to privsep a synchronous program. On top of the IPC concerns of isolation, you still have all the problems associated with threading. It's just pain. (I've written a fair number of both types of systems - none open source unfortunately)
    - tptacek 12y ago
      The original privsep programs weren't async reactor-based designs.
      - bananas 12y ago
        No they were single threaded forked. Aware of that.

yp_all 12y ago

Great story. It is good to know that some programmers do learn over time. For every 1 story like yours there are probably 10 where someone is still traying to get "revenge" by saying nasty things about you know who. Those more common stories get replicated through the wires and the end result is that no one cares about programming anymore; they are simply interested in discussing interpersonal relations. Would you rather have your software written by a foolish programmer who is pleasantly tactful or a competent and conservative one who is tactless? The answer of course varies depending on what you are really after.

JackC 12y ago
> Would you rather have your software written by a foolish programmer who is pleasantly tactful or a competent and conservative one who is tactless? This is a false dichotomy. Interpersonal skills are among the skills necessary to work on a project that involves more than one person. That covers most of the interesting ones. If there's a successful project with someone who lacks those skills, it's because other people are covering for them -- just like a successful project with a foolish programmer. Sometimes that person makes up for it with other things they bring to the table, and that's fine, but don't pretend a weakness is a virtue.

tptacek 12y ago

This is vintage Theo. It has the virtue of sounding correct, but, because OpenBSD ships threaded libraries, it probably lacks the virtue of being correct. I had a similar experience (note, though: I have a history with Theo, who I know/knew personally). When I was at Arbor Networks, we shipped appliances that monitored ISP backbones that were based on OpenBSD. An analysis process that happened to allocate a lot of memory would occasionally lose a giant chunk of memory. I was able to produce a reduction of the bug and narrow down where in the VM subsystem the bug was happening, but I wasn't able to recommend a fix. Theo's response, to what was clearly a serious bug in OpenBSD, was "I'm not going to look at UVM; it's just Chuck Cranor's thesis project". I lobbied for a switch to FreeBSD, but the monkey.org people that ran the place were dyed-in-the-wool for OpenBSD. :)

Flow 12y ago
What happened next? Did the bug get fixed? Did you do a work-around somehow? Don't leave stories unfinished like this :)
- tptacek 12y ago
  I actually don't know. Arbor could have had its dev team hunt for a fix for the bug, but that would have been silly; no way did it make sense for them to take ownership of a custom fork of the most complicated kernel subsystem. So we worked around the problem instead.
gypsyharlot 12y ago
I don't see how his response was unreasonable.
- tptacek 12y ago
  It helps to understand the role a virtual memory system has in an operating system kernel.
  - fabulist 12y ago