naviserver-devel

[naviserver-devel] new vfs changes 2

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

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?

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. 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.
Also: watch: there is a Tcl_DeleteInterp() call too much left there. I
suggest (if you do not have any other reason) to go back to  
Tcl_CreateInterp.
This will save us cycles at that point and we'll loose nothing.

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

Cheers
Zoran

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

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

Re: [naviserver-devel] new vfs changes 2

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

On 10/10/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
> 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?


(Sorry this took a while...)

I dropped acinclude.  All autoconf macros additional to those that
ship as standard with the autoconf package now go in the m4 directory,
whether written by ourselves (dns.m4) or imported from other sources
(tcl.m4).

People who build from tarballs run configure, make, make install, as before=
.

People who build directly from cvs run autogen.sh, make, make install.

The autogen.sh script creates aclocal.m4, uses that and configure.in
to create configure, then runs it.  We no longer keep the configure
script in cvs, as it can be regenerated.  This shouldn't be a problem
in 2005 with all unix like OS shipping with the autotools.