Slashdot Mirror

Try reading some old dragnet scripts for a feel of what it used to be like.

I think they used "citizens" sometimes in the bits before the show talking about the city and more often they used "people" but also used "the public" and "man" and "woman".
I don't recall "civilian" being used.

http://www.otrr.org/FILES/Scri...

There's a blog from 2009 about this
http://pl.atyp.us/wordpress/in...

It looks like the international definition of civilians includes police officers. ("A civilian under international humanitarian law (also known as the laws of war) is a person who is not a member of his or her countryâ(TM)s armed forces or other militia. Civilians are distinct from combatants." )

I've been unable to google when the police started using "civilian" widely. Most states still advertise for "civilian police force" jobs. So the police are explicitly civilian in the state's eyes.

It may be "findable with search" on his site, but I sure as heck haven't been able to find it. Perhaps it's now only searchable by his name (which I don't know), or by something related to the scam. The closest I could find was his blog post on trytobreak.com's scam, which didn't seem to mention any names. So, it seems like it's effectively hidden unless someone is searching specifically for that name, and in that case they'd have to know to search his site for the person's name. It seems pretty effectively hidden.

Interesting point, though, on the slight inconsistency between trusting that someone's moving on from their "idiot stage" and trying to turn their life around enough to make it un-searchable, but not enough to take it down completely.

The comments on the blog post is where his name is revealed.
http://pl.atyp.us/wordpress/?p=831

The real issue I have with the NoSQL people is they're a bunch of whiny babies, who haven't even taken the time to understand the problem before lashing out at the first thing they see.

Yeah, some NoSQL advocates are certainly like that, but do you know what's even worse? The whiny ACID-babies who haven't taken the time to understand the problems that most NoSQL systems are really trying to solve, and are just deathly afraid of having to learn something besides their comfortable RDBMS-tweaking ways. Things really do get a bit different when you have petabytes spread across multiple sites, where even millions spent on Oracle licenses won't really yield a solution. A lot of this work is based on Eric Brewer's CAP Theorem, which was presented as a keynote at PODC in 2004 and has since been formally proven. How's that for a bunch of folks who didn't know what's already out there? Brewer's work was in turn informed by Lamport's (e.g. vector clocks and eventual consistency), who in turn built on others going back at least as far as Codd and the relational model. The simple fact is that you can't have all of C/A/P, some people legitimately value A/P more than C, and C (consistency) in this context includes the I (isolation) of which you seem so enamored. Stonebraker already made the point that this has nothing to do with SQL, and much better than you, but it does have to do with ACID and ACID is simply irreconcilable with some needs. Raising facile objections to the name is a poor substitute for tackling the real issues.

I've written about the cargo cult mentality myself, even in this particular context, anticipating your remarks by at more than a month. Someone here has indeed not taken time to understand the problem before lashing out: you. Please get over the puerile attitude that different knowledge must be inferior knowledge, and educate yourself a little.

I don't mean to attack directly, but you seem to be just well informed enough to be dangerous. First, you seem to think a quick reboot is something that should be no big deal and happen rather often. This is kind of appalling. If you need to reboot a computer often (more than to install new hardware), something serious is wrong with it or it's OS.

Secondly, this phrase, "Hard drives need explicit defragmenting" is misleading as all hell. Hard drives do not need defragmenting. They're made of platters, heads, etc. It's a filesystem that need fragmented. If you want to really nit-pick, it's files within file systems. Still, not hard drives.

Some filesystems are much more prone to fragmentation than others. Namely FAT, FAT32, and NTFS. They have no fragmentation prevention measures. Luckily there are good tools available to defragment them. Other filesystems like ext3 have built in fragmentation-prevention techniques that go a long way, so it's not nearly so big of an issue. They do have defragmentation programs but they don't seem to be trusted by some experts.

As for RAM fragmentation, it's such a non-issue that it's worth explaining. Note that it's Random Access Memory! It's designed to be read randomly. So reading two contiguous blocks is no faster than reading two blocks on opposite ends of the stick or address space. Hence fragmentation is a complete non-issue. And it's a near certainty that your RAM defragger will waste more time than just leaving the RAM alone. Assuming it's not just scamware anyway.

So why does that make your post dangerous? Perpetuating the myth that rebooting is cool and normal is harmful in the long run. It's harder on hardware and hell on uptimes. As is perpetuating the misunderstanding that hard drives need defragmented. Some undereducated, child-of-nepotism CTO might read your post, then take it to heart to the detriment of some entire company and all of their clients. Rebooting machines willy-nilly and attempting to defragment hard drives. In any case, misinformation on a public forum is dangerous, okay?

They make it sound like the decision not to support FF3 was a recent one. Bovine excrement. They'd lost interest months ago, and never intended to add such support. I got tired of waiting a while ago, and even wrote about my switch just this past week. The same thing is happening with lots of other extensions too, such as S3 Organizer which I've also abandoned. There's an old saying that nobody sees the bodies until the tide goes out, and a major release of something like Firefox is the tide going out. That's when you get to find out about all the projects whose developers actually wandered off months ago, but nobody had noticed because nothing had broken yet. Now it's broken. It's not a big surprise in most cases, but it is a little disappointing from an organization with the resources and reputation of Google.

The C10K problem
http://kegel.com/c10k.html

High-Performance Server Architecture:
http://pl.atyp.us/content/tech/servers.html

(Note that this refutes http://ask.slashdot.org/comments.pl?sid=277739&cid =20331189 because this emphasizes that you should do as much work in one thread as possible in order to avoid redundant context switches. Thus don't separate threads based on role where one task must be picked up by many threads to complete -- instead, each thread should be able to execute any sequence through the state machine for any client.)

Maybe not a classic, but still nice (see its references):
Threads, Tasks, Coroutines, Processes, and Events:
http://shlang.com/writing/threads-tasks.html

I don't think that the Linux filesystems require defragmentation though

I already wrote about this four days ago so I won't repeat the whole thing here. Short version:

• Microkernel design, single-address-space implementation: good
• Extensive compile-time checking of code that eventually runs native (not interpreted/JIT): good
• Checking protocol behavior as well as lower-level function contracts: great
• No deadlock/livelock checking: ok for now (it's a hard problem)
• No checking of responses to component failure: oops
• Not even a mention of making it distributed: weird

Even shorter version: lots of great ideas, lots of work still to be done. Anybody with a clue about operating systems should be following this with interest.

Perhaps you would care to define what you consider those "microkernel design principles" to be? Be sure to contrast them against object oriented programming, active objects, and message passing.

Oh, I get it. I'm supposed to distinguish microkernels from other things only in terms of aspects you dislike, allowing you to appropriate anything you do like for "your side" of the debate? Sorry, not falling for it. As I said earlier, both microkernels and OOP are variants of the same basic concept: modularity. Like one, like both. Hate one, hate both. Making arbitrary distinctions for the sole sake of hyping one and dissing the other is dishonest.

Monolithic kernels written in languages like Java make it impossible for components to "twiddle" each other's data

Then such a kernel's not very monolithic, is it? Idiot. What do you call that piece of code that takes care of loading classes and dealing with reflection and garbage collection and other forms of inter-component mediation and safety enforcement in your microkernel-less utopia, Mr. Smartass? Oh, right. It's a microkernel. Sheesh.

Conversely, microkernels frequently "twiddle" each other's data--they just do so by sending requests to do so.

Oh, so Java objects can't exchange messages, or implement trivial getter/setter methods? Yeah, right. The kind of twiddling you mention is trivially possible in any language or environment, whether it be C or Java or Linux or QNX. I've even written about that problem. . .twice, and both before you showed up to be educated. Attributing a problem only to one paradigm when it applies to both is, again, dishonest.

You're just lucky I'm not charging you my usual hourly rate for being your own private tutor. You couldn't afford it, and will never be able to while you have more attitude than knowledge.

Perhaps you would care to define what you consider those "microkernel design principles" to be? Be sure to contrast them against object oriented programming, active objects, and message passing.

Oh, I get it. I'm supposed to distinguish microkernels from other things only in terms of aspects you dislike, allowing you to appropriate anything you do like for "your side" of the debate? Sorry, not falling for it. As I said earlier, both microkernels and OOP are variants of the same basic concept: modularity. Like one, like both. Hate one, hate both. Making arbitrary distinctions for the sole sake of hyping one and dissing the other is dishonest.

Monolithic kernels written in languages like Java make it impossible for components to "twiddle" each other's data

Then such a kernel's not very monolithic, is it? Idiot. What do you call that piece of code that takes care of loading classes and dealing with reflection and garbage collection and other forms of inter-component mediation and safety enforcement in your microkernel-less utopia, Mr. Smartass? Oh, right. It's a microkernel. Sheesh.

Conversely, microkernels frequently "twiddle" each other's data--they just do so by sending requests to do so.

Oh, so Java objects can't exchange messages, or implement trivial getter/setter methods? Yeah, right. The kind of twiddling you mention is trivially possible in any language or environment, whether it be C or Java or Linux or QNX. I've even written about that problem. . .twice, and both before you showed up to be educated. Attributing a problem only to one paradigm when it applies to both is, again, dishonest.

You're just lucky I'm not charging you my usual hourly rate for being your own private tutor. You couldn't afford it, and will never be able to while you have more attitude than knowledge.

I think RTFM is a term that should be abolished. It's used too often by overconfident and undereducated people. They rarely know much about that they're posting about, yet they talk like they're the BE ALL END ALL of the subject.
Let's RTFM here. The Redhat article admits that there is fragmentation on EXT2 and admits that no well established utility exists for fixing this besides recreating the partition. Is that really a solution? Does it really "Just Work?" Further articles on this matter exist:
http://pl.atyp.us/wordpress/index.php?p=241
http://www.uwsg.iu.edu/hypermail/linux/kernel/0203 .1/0539.html

Here it is in one picture.

Wouldn't you know it? I just spent much of the weekend converting my site from my own homegrown weblog codebase to pMachine. Here's the new version (with an entry about the change), and the old version for comparison. According to the table, b2evolution and WordPress would be equally good fits, perhaps even slightly better because they support assigning an entry to multiple categories like my old code but unlike pMachine Free, but when I tried them all out at opensourceCMS that really wasn't the case. I strongly recommend that you check out candidates there, because a lot of the small things make a difference. Here are some examples:

• What kinds of markup is allowed in posts? In comments? Is it plain HTML, or a stripped-down square-bracketed subset like bbCode, or both, or neither? Which are you comfortable with? How about your users who leave comments? If it's real HTML, how are various cross-site scripting and other exploits prevented?
• Are commenters allowed to register so they can have persistent profiles? Are they forced to register? Either/or?
• Does the post entry format allow things like saving drafts, posting to the future, setting expiration dates?
• Does the system have things like time offsets (between where you are and where your site is hosted)? Are the paths that it uses configurable, so you can make it work with different directory structures? How "tunable" are things in general? This can be a huge headache if you get halfway into your transition and you find something that just won't work properly in your environment without hacking the code.
• Do you really like the way the templating system works? You really won't know until you try some customization, so fiddle a bit with the layout. Move stuff around, add links to other parts of your site, etc.
• If you're converting from another system, are there automatic conversion tools? How well do they really work? Again, you have to try to see, and not just on opensourcecms either. If there are no converters, how hard would it be to write one? Does the database schema (and/or file layout) make sense to you? Is it similar conceptually to what you have now? Does it require complex relationships between tables/fields that would be hard to maintain as you suck in your old content? Is there any information in your old content that there's no place for?

These sorts of things, none of which are covered in a mere checklist, really matter when you actually take the plunge. Trying stuff out on opensourcecms is a great first step, but then you should actually download the real thing and really try to run a test version of your own site on it for at least an hour or so, to see if you can truly tweak it to your liking. Only then will you be able to make a decision that will really satisfy you.

Wouldn't you know it? I just spent much of the weekend converting my site from my own homegrown weblog codebase to pMachine. Here's the new version (with an entry about the change), and the old version for comparison. According to the table, b2evolution and WordPress would be equally good fits, perhaps even slightly better because they support assigning an entry to multiple categories like my old code but unlike pMachine Free, but when I tried them all out at opensourceCMS that really wasn't the case. I strongly recommend that you check out candidates there, because a lot of the small things make a difference. Here are some examples:

• What kinds of markup is allowed in posts? In comments? Is it plain HTML, or a stripped-down square-bracketed subset like bbCode, or both, or neither? Which are you comfortable with? How about your users who leave comments? If it's real HTML, how are various cross-site scripting and other exploits prevented?
• Are commenters allowed to register so they can have persistent profiles? Are they forced to register? Either/or?
• Does the post entry format allow things like saving drafts, posting to the future, setting expiration dates?
• Does the system have things like time offsets (between where you are and where your site is hosted)? Are the paths that it uses configurable, so you can make it work with different directory structures? How "tunable" are things in general? This can be a huge headache if you get halfway into your transition and you find something that just won't work properly in your environment without hacking the code.
• Do you really like the way the templating system works? You really won't know until you try some customization, so fiddle a bit with the layout. Move stuff around, add links to other parts of your site, etc.
• If you're converting from another system, are there automatic conversion tools? How well do they really work? Again, you have to try to see, and not just on opensourcecms either. If there are no converters, how hard would it be to write one? Does the database schema (and/or file layout) make sense to you? Is it similar conceptually to what you have now? Does it require complex relationships between tables/fields that would be hard to maintain as you suck in your old content? Is there any information in your old content that there's no place for?

These sorts of things, none of which are covered in a mere checklist, really matter when you actually take the plunge. Trying stuff out on opensourcecms is a great first step, but then you should actually download the real thing and really try to run a test version of your own site on it for at least an hour or so, to see if you can truly tweak it to your liking. Only then will you be able to make a decision that will really satisfy you.

Sure you need a thread pool. Creating a new thread, does not only allocate a thread object, but it likely makes a kernel call to get a new thread handle. You pool to avoid the kernel call. Not to avoid the memory allocation/deallocation.

"Throw off the shackles and learn to program network servers."

...and found this under the "Lock Contention" heading:

"Dividing code into stages is a complicated matter of program design, so there's not much I can offer there"

The inevitable disclaimer buried in the majority of all literature attempting to discuss concurrency. Try this for a practical remedy.

= 9J =

The new linux kernel is great, but the reason the this particlular kernel results is better performance ("5 times better") is because the application framework it is testing is horrible.

All of the "enterprise" applications in this test have several performance cripling features in common: socket per thread connections, fundemental reliance on threads, and massive memory foot print. Apache has one thread/process (the diff is a stack) per connections. Java requires a sizable multiple of memory usage as most other application languages (C/C++ obviously, but also Perl, Python, and PHP). J2EE is an inherently thread driven programming framwork.

So yes, Linux 2.6 ameliorates the downsides of unnecessary use of threading. It makes thread creation and context switching even faster on the Linux platform.

And Yes, Linux 2.6 memory management is fundementally better. Reverse Page Table Entry mappings make finding victim pages better; and it is designed to avoid victimizing active pages better.

But could you all imagine if people were designing fundementally better application framworks? Event driven application architectures like TwistedPython and POE, or Event-thread hybrid systems like SEDA.

The performance stats given in that article are shit, complete utter shit. I know. In the proprietary world I work in, I code faster programs on the same Linux platform on a daily basis; orders of magnitude faster.

All the accomplishments of Linux 2.6 can be used for true performance programming. I plead with you all, stop using Threads until you know what they are good for. Stop using the stack to maintain your program state. Throw off the shackles and learn to program network servers.

'For many, the best analogy for the way DNA works is that it's like a computer program at the heart of every cell. Some of its programming tricks bear an uncanny resemblance to ones the human brain has dreamed up...DNA is [like] spaghetti code because nature has been tinkering with the system for billions of years like a bad programmer.'

Queuing approaches have proven to be much more scalable in other areas - no reason to think it wouldn't work for web servers. Check out SEDA: An Architecture for Highly Concurrent Server Applications for a working implementation in Java that outperformed Apache [insert benchmark caveat here].

More on event-driven servers that minimize data copies and context-switching here.

-dB

If you have a thousand connections, are you better off with 1000 threads, or one/a few in select, and ~4*NCPU workers?

Neither. ;-) Listener/worker separation is a fundamentally flawed model; try symmetric multithreading instead.

If you have a thousand connections, are you better off with 1000 threads, or one/a few in select, and ~4*NCPU workers?

Neither. ;-) Listener/worker separation is a fundamentally flawed model; try symmetric multithreading instead.

anyone who runs more than about 4*NCPUS threads in a program is an idiot

I'd look at it a different way, and count likely-to-be-active threads. If that number's much greater than NCPUS you're probably hurting yourself, but threads that are certain or almost certain to be sleeping (e.g. periodic tasks that are between invocations) don't really count. I discuss this issue more in an article on my website about avoiding context switches (part of a larger article about server design) if you're interested.

applications where deadlocks or race conditions would be an integral problem in a multithreaded implementation whilst a single thread has none of these problems.

That's a common myth. In fact, there are some kinds of deadlock that do go away, but there are also some kinds that merely change their shape. For example, the need to lock a data structure to guarantee consistent updates goes away, and so do deadlocks related to locking multiple data structures. OTOH, resource-contention deadlocks don't go away. You might still have two "tasks" contending for resources A and B, except that in the non-threaded model the tasks might be chained event handlers for some sort of state machine instead of threads. If task1 tries to get A then B, and task2 tries to get B then A, then task1's "B_READY" and task2's "A_READY" events will never fire and you're still deadlocked. Sure, you can solve it by requiring that resources be taken in order, but you can do that with threads too; the problem's solvable, but isn't solved by some kind of single-threading magic.

I've written several articles on this topic for my website in the past. In case anyone's interested...

• multi-threading vs. event-based scorecard
• symmetric vs. asymmetric multithreading
• some micro-benchmarks
• the "threading's too hard" canard
• switching models
• minimizing context switches

applications where deadlocks or race conditions would be an integral problem in a multithreaded implementation whilst a single thread has none of these problems.

That's a common myth. In fact, there are some kinds of deadlock that do go away, but there are also some kinds that merely change their shape. For example, the need to lock a data structure to guarantee consistent updates goes away, and so do deadlocks related to locking multiple data structures. OTOH, resource-contention deadlocks don't go away. You might still have two "tasks" contending for resources A and B, except that in the non-threaded model the tasks might be chained event handlers for some sort of state machine instead of threads. If task1 tries to get A then B, and task2 tries to get B then A, then task1's "B_READY" and task2's "A_READY" events will never fire and you're still deadlocked. Sure, you can solve it by requiring that resources be taken in order, but you can do that with threads too; the problem's solvable, but isn't solved by some kind of single-threading magic.

I've written several articles on this topic for my website in the past. In case anyone's interested...

• multi-threading vs. event-based scorecard
• symmetric vs. asymmetric multithreading
• some micro-benchmarks
• the "threading's too hard" canard
• switching models
• minimizing context switches

applications where deadlocks or race conditions would be an integral problem in a multithreaded implementation whilst a single thread has none of these problems.

That's a common myth. In fact, there are some kinds of deadlock that do go away, but there are also some kinds that merely change their shape. For example, the need to lock a data structure to guarantee consistent updates goes away, and so do deadlocks related to locking multiple data structures. OTOH, resource-contention deadlocks don't go away. You might still have two "tasks" contending for resources A and B, except that in the non-threaded model the tasks might be chained event handlers for some sort of state machine instead of threads. If task1 tries to get A then B, and task2 tries to get B then A, then task1's "B_READY" and task2's "A_READY" events will never fire and you're still deadlocked. Sure, you can solve it by requiring that resources be taken in order, but you can do that with threads too; the problem's solvable, but isn't solved by some kind of single-threading magic.

I've written several articles on this topic for my website in the past. In case anyone's interested...

• multi-threading vs. event-based scorecard
• symmetric vs. asymmetric multithreading
• some micro-benchmarks
• the "threading's too hard" canard
• switching models
• minimizing context switches

applications where deadlocks or race conditions would be an integral problem in a multithreaded implementation whilst a single thread has none of these problems.

That's a common myth. In fact, there are some kinds of deadlock that do go away, but there are also some kinds that merely change their shape. For example, the need to lock a data structure to guarantee consistent updates goes away, and so do deadlocks related to locking multiple data structures. OTOH, resource-contention deadlocks don't go away. You might still have two "tasks" contending for resources A and B, except that in the non-threaded model the tasks might be chained event handlers for some sort of state machine instead of threads. If task1 tries to get A then B, and task2 tries to get B then A, then task1's "B_READY" and task2's "A_READY" events will never fire and you're still deadlocked. Sure, you can solve it by requiring that resources be taken in order, but you can do that with threads too; the problem's solvable, but isn't solved by some kind of single-threading magic.

I've written several articles on this topic for my website in the past. In case anyone's interested...

• multi-threading vs. event-based scorecard
• symmetric vs. asymmetric multithreading
• some micro-benchmarks
• the "threading's too hard" canard
• switching models
• minimizing context switches

applications where deadlocks or race conditions would be an integral problem in a multithreaded implementation whilst a single thread has none of these problems.

That's a common myth. In fact, there are some kinds of deadlock that do go away, but there are also some kinds that merely change their shape. For example, the need to lock a data structure to guarantee consistent updates goes away, and so do deadlocks related to locking multiple data structures. OTOH, resource-contention deadlocks don't go away. You might still have two "tasks" contending for resources A and B, except that in the non-threaded model the tasks might be chained event handlers for some sort of state machine instead of threads. If task1 tries to get A then B, and task2 tries to get B then A, then task1's "B_READY" and task2's "A_READY" events will never fire and you're still deadlocked. Sure, you can solve it by requiring that resources be taken in order, but you can do that with threads too; the problem's solvable, but isn't solved by some kind of single-threading magic.

I've written several articles on this topic for my website in the past. In case anyone's interested...

• multi-threading vs. event-based scorecard
• symmetric vs. asymmetric multithreading
• some micro-benchmarks
• the "threading's too hard" canard
• switching models
• minimizing context switches

applications where deadlocks or race conditions would be an integral problem in a multithreaded implementation whilst a single thread has none of these problems.

That's a common myth. In fact, there are some kinds of deadlock that do go away, but there are also some kinds that merely change their shape. For example, the need to lock a data structure to guarantee consistent updates goes away, and so do deadlocks related to locking multiple data structures. OTOH, resource-contention deadlocks don't go away. You might still have two "tasks" contending for resources A and B, except that in the non-threaded model the tasks might be chained event handlers for some sort of state machine instead of threads. If task1 tries to get A then B, and task2 tries to get B then A, then task1's "B_READY" and task2's "A_READY" events will never fire and you're still deadlocked. Sure, you can solve it by requiring that resources be taken in order, but you can do that with threads too; the problem's solvable, but isn't solved by some kind of single-threading magic.

I've written several articles on this topic for my website in the past. In case anyone's interested...

• multi-threading vs. event-based scorecard
• symmetric vs. asymmetric multithreading
• some micro-benchmarks
• the "threading's too hard" canard
• switching models
• minimizing context switches

you could keep an item in your own store by requesting it automatically every so often.

Unfortunately, that doesn't really work. See my Freenet FIQ (Frequently Ignored Questions) for an explanation.

I who thought that FreeNet was meant as a tool to disclose information about those governaments

Um, yes, well. Check out Saving the Whales Using Freenet from last March. Despite the fact that Ian and many other Freenetistas regularly read my site, I have yet to receive any pointers to info about actual instances of Freenet being used in such ways. For that, you might try Peekabooty instead.

It's nice to know there are others out there who know state machines are the One True Way

Oh, but they're not. Yes, I know you were joking, but it's also a serious matter and a mistake many people make. I love state machines, I'm notorious among my past and present coworkers for using them, but they're not the only way to break out of the naive multithreaded model. In fact, naive state-machine implementations are often even worse than naive multithreaded implementations since they're all too often utterly incapable of using more than one CPU.

The best-known alternative to the two representatives of this false programming-paradigm dichotomy is probably Matt Welsh's SEDA. I've also written extensively on the subject: here's an archive of past articles and my server-design guide that sums it all up. The basic idea, which goes back much further than either my work or Matt's, is to break processing into stages. Interactions between stages are asynchronous event- or message-based, while what occurs within a stage can be either state-oriented or thread-oriented according to programmer preference, availability of non-blocking I/O interfaces, etc. The programmer thus has a great deal of control over how a task-appropriate balance between the relative advantages and drawbacks of the two "standard" models is achieved.

Ideally you have exactly as many threads as CPUs

An excellent point. In fact, this is the area where Matt's thinking and mine diverge, and thus deserves special attention. SEDA tends a little toward the bounded-thread-pool model of having more threads than processors (though not infinite) and I believe that's a mistake. My own model more sharply limits the number of threads that are used. Though there might transiently be more active threads than processors under certain conditions, this is not a persistent condition; it's simply more costly to eliminate those rare transient cases than to allow them. Another difference is that SEDA attempts to reduce context switches and stage transitions by "batching" (passing multiple requests through a stage in a single pass) whereas I tend more towards "run until completion" (passing a single request through multiple stages). While the two approaches are probably equivalent in most ways, I believe the latter has a cache-warmth advantage; there's usually more data shared between the processing of a single request through multiple stages than between multiple requests in one stage.

I guess we're getting a little off-topic, though. Maybe we should find an alternate venue to discuss this if people are interested.

It's nice to know there are others out there who know state machines are the One True Way

Oh, but they're not. Yes, I know you were joking, but it's also a serious matter and a mistake many people make. I love state machines, I'm notorious among my past and present coworkers for using them, but they're not the only way to break out of the naive multithreaded model. In fact, naive state-machine implementations are often even worse than naive multithreaded implementations since they're all too often utterly incapable of using more than one CPU.

The best-known alternative to the two representatives of this false programming-paradigm dichotomy is probably Matt Welsh's SEDA. I've also written extensively on the subject: here's an archive of past articles and my server-design guide that sums it all up. The basic idea, which goes back much further than either my work or Matt's, is to break processing into stages. Interactions between stages are asynchronous event- or message-based, while what occurs within a stage can be either state-oriented or thread-oriented according to programmer preference, availability of non-blocking I/O interfaces, etc. The programmer thus has a great deal of control over how a task-appropriate balance between the relative advantages and drawbacks of the two "standard" models is achieved.

Ideally you have exactly as many threads as CPUs

An excellent point. In fact, this is the area where Matt's thinking and mine diverge, and thus deserves special attention. SEDA tends a little toward the bounded-thread-pool model of having more threads than processors (though not infinite) and I believe that's a mistake. My own model more sharply limits the number of threads that are used. Though there might transiently be more active threads than processors under certain conditions, this is not a persistent condition; it's simply more costly to eliminate those rare transient cases than to allow them. Another difference is that SEDA attempts to reduce context switches and stage transitions by "batching" (passing multiple requests through a stage in a single pass) whereas I tend more towards "run until completion" (passing a single request through multiple stages). While the two approaches are probably equivalent in most ways, I believe the latter has a cache-warmth advantage; there's usually more data shared between the processing of a single request through multiple stages than between multiple requests in one stage.

I guess we're getting a little off-topic, though. Maybe we should find an alternate venue to discuss this if people are interested.

I've often meditated about the guild parallel too. One aspect that particularly intrigues me is the idea of a guild house as a social/developmental/contact-making focus. Right now, people try to use their employer (or possibly their body shop) in that role, and it's a role in which those other-directed organizations are destined to fail.

In a slightly different vein, I wrote an article a while ago about yet another way to reason about developer capabilities and inclinations. It's mostly orthogonal to the guild approach, or perhaps even irreconcilable with it, but it might be interesting nonetheless.

...not after this observation I made last year. No, it's not proof of anything at all. It's just one more tiny piece of some puzzle; decide for yourself what you think it means.