I can take this only so long before replying... POSIX threads are a complete a total disaster. They are essentially non portable. Anyone who has written threaded code that has to be portable has at one point considered suicide. We are not talking about running on OpenBSD and Linux here; we are talking about running on virtually ALL operating systems. If you honestly believe you can make that work reliably and securely you have never written any portable code of any significant size.
The discussion on kernel threads is irrelevant. It is not about having some lower level support that will magically make threads not suck. The threading model is inherently flawed. Again writing a program of any size will teach you this lesson the hard way; especially if you have the honor of being part of a team of 500 people. Nothing is more fun than having short lived threads silently corrupting the heap in 100% non reproducible ways. Let the finger pointing begin... But don't believe me, try it for yourself. Write a program that listens on sockets in a thread and have them signal an external entity when they wake up. Have the external entity acknowledge the signal by returning a different signal. Oh and make that work on Linux 2.0, 2.2, 2.4 & 2.6. When you get that right go port it the BSDs. Oh and the advanced hacker does this without #ifdef. Have fun. All this aside do you honestly think that ssh is slow and needs a "boost"? I don't know about you but decrypting one character as soon as I type it works well enough for me. Benchmarking often is stupid and yields results that are wildly misinterpreted. The performance numbers sure show that it is faster and therefore better right? Quite the opposite. We are talking about one of the most attacked pieces of software in the history of the internet people. Faster != better AT ALL. On Wed, Feb 13, 2008 at 11:46:25PM -0600, Matthew Weigel wrote: > Geoff Steckel wrote: >> This discussion of threads is isomorphic to: >> >> Why do CPUs have MMUs? >> Why don't we write "good guys' timeshared programs" which run >> cooperatively and noninterfering in a shared unprotected >> environment? >> >> Answer: it's too hard to write perfect programs. >> Compartmentalized security simplifies each component and >> drastically simplifies keeping the whole system running well. > > Yes, it is. > >>> It's controlled by the code you write. >> >> That makes it implicit and/or accidental. Data sharing between any parties >> must >> be explicit and declared, otherwise it is either a bug now >> or a bug later when the next maintainer doesn't know. >> Accidental state sharing is by definition a fatal bug. > > How is it qualitatively more implicit than IPC? > >>>> they encode state implicitly in the program counters of the threads >>> >>> The hell? >> OK, you're debugging a multithreaded program. Quick, what's the state >> of all the threads now? Not encoded in data? Hmmmmmmmmmm.... how long >> is it going to take to discover it. > > Have you ever had to debug a multi-threaded application? You can use a > debugger to check the state just the same. > >>>> they are extremely difficult to guard against external conditions >>>> such as unexpected incoming data >>> >>> Incoming from where? >> Any useful program does I/O. Otherwise the computer is a space heater. >> So, other than pattern generators with built in data, every useful >> program must take input. Any multithreaded program which I've observed >> has some form of asynchronous inputs. Now, what happens when an unexpected >> datum arrives. > > So it's expected in the sense that "there is a thread looking for input on > this file descriptor." But it's unexpected in the sense of... how? > >>>> complete and correct error recovery requires complex and error prone >>>> code >>> >>> Welcome to "non-trivial software development." >> >> That's exactly the point. Subtle but extremely important. >> Every effort must be made to keep the software as simple as possible >> so that it is comprehensible. Incomprehensible software is by >> definition a fatal bug. > > The point is that all non-trivial software development has the problem that > complete and correct error recovery requires complex and error-prone code? > >> Any construct which causes complexity disproportionate with the >> total system gain (development & maintenance resources, run time resources, >> etc. vs useful output) must be avoided. > > Finally, something we agree on. Make the code as simple as you can - but > no simpler (to paraphrase Einstein). Look, all of these issues - *all* of > them - are exactly the sorts of problems that the developers need to get a > handle on in order to support the SMP kernel, never mind kernel threads. > If they can't get it right, then they might as well say so, and we can all > go back to uniprocessor machines for anything secure, and run Linux or > FreeBSD for anything performance-sensitive. > > Now, I haven't looked at the exact code written, but based on the > descriptions I'm guessing it's a worker thread model where discrete units > of work are parceled out, performed, and returned. This has got to be the > easiest model of threading to get right, the easiest model to verify, and > entirely appropriate for the problem described (processing independent > blocks). > > This is the same model, albeit with better performance characteristics > (assuming kernel threads), that Apache uses, and one of the great things > about this model is that it's very easy to tightly control what memory > threads share. But the response here has been an uninformed kneejerk > response to 'threads' and how they're hard to get right, without anyone > realizing that this particular model is actually *not* hard to get right. > -- > Matthew Weigel > hacker > unique & idempot.ent
