Am 31.12.2005 um 15:27 schrieb Gustaf Neumann:
Maybe, the receiving thread is not needed at all, since the driver thread could handle everything as well.
This is what I ment. Driver thread is very hot as it does not (should not?) find iself into any blocking at all. At the moment it does, as it writes into a mmaped file when somebody uploads a thing larger that would fit in a predefined buffer. But this should be avoided. Precisely that's the reason why I'm contemplating the kaio as this would allow the driver thread to run at highest possible speed. The locking. In order to get any meaningful statistics, there have to be places to hook into that processing which will inevitably lead to locks. But, OTOH, how frequent would that be? We are talking about very short and relatively seldom lock attempts. I can't say it out of the sleeve, but I somehow have a feeling that locking would not be an issue here. Or? Other kind of processing (like quota enforcing etc). This would/could be pretty difficult as I wouldn't like to run any Tcl code from within the driver thread. So, if this need be done, than we must thing of some bit toggling and signalling the driver thread to abort/stop/whatever the upload process if needed. Just my 2 cents. Cheers Zoran
