On 6/1/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > > Am 01.06.2005 um 14:10 schrieb Stephen Deasey: > > > On 5/30/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > > > >> > >> Am 30.05.2005 um 12:01 schrieb Stephen Deasey: > >> > >> > >>> > >>> What's the return value of Ns_FSOpen? > >>> > >>> > >> > >> Something that can be fed to Ns_FSRead and/or Ns_FSClose > >> for example. I haven't started the implementation yet > >> but this is first what comes to mind. > >> > >> Presumably, it will be Tcl_Channel in VFS or a regular > >> OS filehandle w/o VFS. > >> > > > > > > The return type would be unknown unless the caller also used #ifdef? > > The return value is of course opaque and should be returned > to the FS abstraction layer. But I read on... > > > > > 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 :-) > > > > Of course, all you say holds. If you need to go to the max when > accesing files, then Tcl VFS will not be the fastest kid on the block. > > But what about this: we make a Ns_FS wrappers and put them in place, > even in the fastpath and adp code. We also add Ns_FSGetOSHandle which > will then return invalid handle to the caller if the file is not located > on the native filesystem. This is trivial and costs no performance. > Now, the caller can accomodate for that and decide what to do. > A very good example is the actual fastpath code which does the same > with the mmap. It works-around the fact that mmap is not defined in > the server config and uses simple open/read/close sequence. > > This way you'd be free to add whatever fancy roaring implementation > (kaio for example) to get the max-speed, if you like. > We need only cover access to files, no sockets, pipes, etc. > What we'd need is just a handful of calls: > > open, close, stat, seek, read, write, opendir, readdir, closedir, > getcwd > > (did I forgot something?) > > Most of them would use the opaque file-handle from which you can > obtain the OS handle to make any private speed optimizations. If the > handle cannot be obtained, then you provide the best-effort fallback. > > What would/could be wrong with that?
Sounds good.
