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?
Zoran
