On 6/14/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > > Am 01.06.2005 um 20:19 schrieb Zoran Vasiljevic: > > >> I don't see anything wrong with using Tcl_VFS* directly to read the > >> config file, write to a log file etc., and the tcl commands in > >> nsd/tclfile.c should be replaced by simple Tcl wrappers anyway. It's > >> the stuff in nsd/fastpath.c that's important. File descriptors need > >> to be available for use with modern, high performance system calls > >> with a minimum of conditional compilation/execution. > >> > >> This also has the potential to be a never-ending bug hunt. > >> Absolutely > >> every call to the file system has to be converted to Tcl_VFS* or > >> Ns_VFS*, including all modules and the libraries they wrap, or people > >> will be surprised... > > > >> I'm not against this feature, but it's pretty esoteric and the > >> implementation is invasive so the quality bar needs to be set high. > >> I'm sure you can do it :-) > > > > > I have thought about all this... > > We do have consensus on fact that fastpath code is actually the > core of the performance respective the filesystem access. All > other parts where files are read and/or written is not speed > relevant. Correct? > > Now, if I simplify the above task by making the *rest* of the > server VFS aware (replacing all native FS calls with Tcl wrappers) > and add one additional config-option to fastpath code like the > mmap is today? > So, one who needs to serve pages out of container files, would > simply toggle the: > > ns/server/$server/fastpath/vfs > > switch to 1 (the default would be zero: not use vfs). > This way, the task is pretty simple and straight-forward. > > What do you think?
How will you load modules at startup? dlopen() etc. take a file name.
