Re: [naviserver-devel] new vfs changes 2

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

On 10/9/05, Zoran Vasiljevic <zv...@ar...> wrote:
> Hi!
>
> Stephen, I see you did checkout those. I wonder how you found all those
> minor signedness problems? I am always compiling with -Wall and compiler
> did not tell me anything, i.e. the compilation went 100% clean?

It's a new gcc thing.  I'm using 4.0.1 on FC4.

> Also, please look in the modload.c about creating new interp before
> Tcl_FSLoad.
> I deliberately used Tcl_CreateInterp and not Ns_TclAllocateInterp
> because of the speed.

Me too!

> At that point, the interp is really only needed for
> error reporting. I even wanted to change Tcl calls to accept NULL
> instead
> but this was too much changes and I did not want to argue about that
> on the
> Tcl core list. Hence, I took the least cost path.

But you need an interp for every module you load, and you still need
one to source the init.tcl boot script and source all the module tcl
files.  The AllocateInterp calls cache interps per-thread, I'm
guessing it's faster.

What I really had in mind here though was a change I made to the
loading of modules.  I was sure I checked that in a long time ago,
looks like I forgot...  It's in there now.

The idea is to move the module loading decisions into the init.tcl
file via the new ns_moduleload command.  With this in place, there has
to be an interp allocated before you even begin to load binary
modules, which is why I thought the calls to allocate an interp would
win out over creating them fresh each time.

My original motivation for this was to make it easier to change the
directory layout of the installation.  I want to locate a module and
it's tcl files in a module directory.  It will be much easier to do
this from Tcl.  Also, the module loading has an extremely complex
ordering, and this hopefully makes that more transparent.

> Also: watch: there is a Tcl_DeleteInterp() call too much left there.

Woops, fixed.

> And, I see that the VFS changes did not broke anythig (well, apart
> from that
> DVS stuff and MIN/MAX) all went fine, or?

(found where MIN and MAX live...  :-)


I don't think it's necessary to call open() and then Tcl_FSOpen(), no
matter how speed critical we think that section of code is.  The Tcl
wrappers can't possible be that slow, it's confusing code to read, and
it may possibly be confusing at run time depending on which files live
where.  There will also be an extra sysytem call for every 404 Not
Found served.  Can we just use the Tcl FS calls throughout?


I was going to complain about your #ifdef __APPLE__ stuff, but
realised there's some infrastructure I hadn't checked in  :-)   I've
changed our autotools setup so that you should now be able to do this:

Go to the Autoconf Archive:  http://ac-archive.sourceforge.net/

Get the AC_CHECK_STRUCT_FOR macro:
http://ac-archive.sourceforge.net/Miscellaneous/ac_check_struct_for.html
and place it into the new m4 sub directory.

Add something like the following to configure.in:

AC_CHECK_STRUCT_FOR([
#include <sys/types.h>
#include <netinet/in.h>
],sockaddr_in, sin_len)

Check for STRUCT_SOCKADDR_HAS_SIN_LEN within nsd/dns.c and code accordingly=
.


Checking for features, not platforms is the way to go.  Apple get
their stuff from Net and Free BSD, so we probably have the same
problem with sockaddr there.  And Apple just may get around to fixing
it one day, too.

Unfortunately, I couldn't get that last step to work.=20
AC_CHECK_STRUCT_FOR doesn't turn up in aclocal.m4.  Not sure what's
up, maybe you have some ideas?


I'll look at this later, there's some pie with my name on it...