Re: [naviserver-devel] new vfs changes 2

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

Am 10.10.2005 um 02:17 schrieb Stephen Deasey:
>
> 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.

Right... this is better.

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

Where this come in? I mean ns_moduleload?

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

Sure we can. I coded this with OS/FS fallback in order to keep
the "hey, it runs much slower now" complaints off my back. Agrreed about
404 (that was an inevitable side-effect). Those fallbacks are really  
only
in the adpeval, fastpath and urlopen at couple of places. I will prune
them and use FS instead.

>
>
> 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.
> AC_CHECK_STRUCT_FOR doesn't turn up in aclocal.m4.  Not sure what's
> up, maybe you have some ideas?

Eh... needles to say that I do not really understand all this autoconf
machinery. I was used to make a configure.in and hit autoconf. Now it
seems that all gotten much more complicated. For example, when do I
need acinclude.m4? Do I make it by hand or somebody is creating this
for me? What about aclocal.m4? I used to edit this by hand, it gets
created now automatically? What I miss (in order to better understand)
is a birds-eye view on the build machinery: what I need to supply by
hand and what is automatically created and what I have to run in order
to get those automatically created). Do you happen to have some info
on that?

After fiddling with autoconf I'm still not able to get

#ifdef STRUCT_SOCKADDR_IN_HAS_SIN_LEN
...
#endif

trigger during the compile. I guess this is because something is
missing in the include/nsconfig.h...

Cheers
Zoran