From: Zoran V. <zv...@ar...> - 2006-01-12 09:20:45
|
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 |