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
