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

[Zoran V. <zv...@ar...>]

Am 01.06.2005 um 14:10 schrieb Stephen Deasey:

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

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