Re: [naviserver-devel] Re: RFE #1202462

[Stephen D. <sd...@gm...>]

On 5/30/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 30.05.2005 um 12:01 schrieb Stephen Deasey:
>=20
> >
> > What's the return value of Ns_FSOpen?
> >
>=20
> 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.
>=20
> 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.=20
I'm sure you can do it  :-)