Am 12.01.2006 um 09:55 schrieb Gustaf Neumann:
the recent discussion was however, to generalize this further and
use such thread for
sending and receiving, thus the proposed name "spooling-thread".
Having such specialized thread as part of the server is great
gain (no external modules, optimal speed, etc). Later on we
can go to further extent and incorporate some kind of AIO
in the thread to scale it even further up. The built-in fastpath
code can transparently gain from this thread by delegating
the dumb work of copying bytes from files to sockets and releveing
the connection thread for real dynamic content tasks.
IOW there are many reasons to make this as compact and as fast
as possible and built into the server. So, we'll have a real
beast capable of equally serving static AND dynamic content
with the highest possible speed.
I do not know how much work that be, but it seems to me that
a spool-thread could take this task. Depending on the number
of CPU's in the box, we might start one or two or four such
things. As the GHz-frenzy has deteriorated and more chip makers
produce dual/quad chips we'll immediately gain from the hardware.
From the API side, we could re-route some commands sending output
to transparently use this (new) infrastructure w/o programmer's
influence.
Well, there are MANY reasons why we'd opt to do it within the server
as oposed to a Tcl-crafted solution. The proof of concept is already
done, as you have very good experience with the thing, by using the
trick with channel passing and a dedicated event-loop based thread.
We'd really have to elevate it to a higher level with a writer or
spooler or writer/spooler thread, however it eventually gets
implemented.
I'm really excited about all this... ;-)
Cheers
Zoran
