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

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

On 6/1/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 01.06.2005 um 14:10 schrieb Stephen Deasey:
>=20
> > On 5/30/05, Zoran Vasiljevic <zv...@ar...> 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?
>=20
> The return value is of course opaque and should be returned
> to the FS abstraction layer. But I read on...
>=20
> >
> > 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...
>=20
> > 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  :-)
> >
>=20
> 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.
>=20
> 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.
>=20
> 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:
>=20
>    open, close, stat, seek, read, write, opendir, readdir, closedir,
> getcwd
>=20
> (did I forgot something?)
>=20
> 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.
>=20
> What would/could be wrong with that?


Sounds good.