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 issue is not preferring open over Tcl_VFSOpen, and it's not mmap per se. mmap is just one example of a function which requires a file descriptor or real files in the file system. sendfile is another, as are readv/writev, epoll, kqueue, inotify, etc. The Tcl VFS is a lowest common denominator abstraction over file systems. It provides the common things, but can't provide implementations of everything, nor can it return a useful file descriptor from a Tcl_Channel, at least in the case where everything is contained within one big file. I think Ns_TclGetOpenFd is going to fail. 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 :-)
