On Sat, 2 Sep 2000, Alexander Viro wrote:
> *threads* *are* *hard* *to* *write* *correctly*
in C, yes that can be essentially true.
although you can do a webserver with no mutexes pretty easily... the first
threaded apache had exactly one mutex -- inside the memory allocator when
it had to go to a list of free pages (which is the slow path -- apache's
fast allocation path needs no mutexes). otherwise the threads
successfully ran without any need to co-ordinate with each other. the
kernel provided all the co-ordination necessary through accept().
i should have chosen my phrasing a bit better too -- when i was talking
about the spectrum between fully threaded and fully state driven, and i
said that "threads are easier to program" i was actually thinking more
along the lines of "call-return stacks make programming a lot easier"...
although that too is totally related to the languages we generally choose
to code in these days. my biggest beef with state-machine coding is that
there's essentially no call-return stack.
although you know the most amusing thing to watch a thread programmer try
to do is to pass data bidirectionally between two sockets.
can we be friends and say "everything in moderation including moderation
itself"? :)
-dean
p.s. you lectured me on optimising only that which needs optimising...
that is exactly what i was suggesting. the only time apache, for example,
needs a state machine is to handle the low bandwidth clients/long
downloads. writing the whole server as a state machine is an essentially
impossible task... if you don't believe me then i suggest trying it.
don't forget to make your server extensible, and plan for perl, php, and
java application services. that's the way people program the web, no
amount of ranting on linux-kernel is going to change it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 02 2000 - 05:58:32 EDT