Eric S. Raymond <e...@thyrsus.com>:
> John D. Bell <j...@systemsartisans.com>:
> > *If* I were the architect on this project (thankfully I'm not!) I
> > would get the code simplified and streamlined in single-thread mode
> > as far as possible, and then design and code a
> > POSIX-threading-conformant "improvement".
>
> That is exactly the contingency plan I have unless Higher Authority (Mark
> and LF) tells me we need to do something else and do it now.
I should amplify that a little.
I will not willingly take the complexity hit of multithreading *anything*
until I see benchmark numbers demonstrating a bottleneck that can be
effectively addressed in no other way. It's not good enough to just handwave
and say "high load, we gotta optimize" - without measurements optimization
is premature and you know what *that* means.
I can certainly do concurrent programming when I have to (there's a thread-pool
scheduler in the cvs-fast-export front end that I'm quite proud of - less than
30 lines of code to manage concurrent Bison parsers and the thing runs like
a bat out of hell) but I have an ingrained reluctance to do it that I've
been explaining off-list to Hal.
Human beings simply aren't very good at the kind of reasoning
concurrent programming requires. Even most programmers handle it
poorly. Thus, while adding threading might be a fun stunt for someone
at the mastery level of Hal or Gary or myself, it's a burden we should
think twice about laying on our successors.
All this comes under one of the least obvious but most important jobs
of a system architect - *defending simplicity*.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
