naviserver-devel — Developer discussion

Re: [naviserver-devel] ns_atstartup and order of execution?

[Vlad S. <vl...@cr...>]

Thanks,

I am slowly starting adjusting to local time and completing reading 
hundreds of emails i've got after more than 2 weeks without email and 
Internet. :-))

Zoran Vasiljevic wrote:
> 
> Am 19.10.2005 um 19:46 schrieb Vlad Seryakov:
> 
>> I have no objections
>>
> 
> Hey!
> 
> Welcome back!
> 
> Zoran
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] ns_atstartup and order of execution?

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

Am 19.10.2005 um 19:46 schrieb Vlad Seryakov:

> I have no objections
>

Hey!

Welcome back!

Zoran

Re: [naviserver-devel] ns_atstartup and order of execution?

[Vlad S. <vl...@cr...>]

I have no objections

Zoran Vasiljevic wrote:
> Hi !
> 
> We have a pretty elaborate (and sometimes confusing) mechanism
> for running various atXXX scripts.
> 
> So, if I would like to:
> 
>   ns_atstartup X
>   ns_atstartup Y
>   ns_atstartup Z
> 
> then the server will execute:
> 
>   Z
>   Y
>   X
> 
> i.e. in the *reverse* order. This is because all of those
> are just entered in a single-linked list and the head of
> the list points always to the *last* registered item.
> 
> This is suboptimal.
> 
> In many real world scenarios, I will like to use the ns_atstartup
> to schedule couple of scripts to do various initialization things.
> It is often so that Y will depend on X and Z on Y to be successfull.
> At the moment, I'm (mis)using the ns_job with a single thread and
> post the jobs there, because it will then exectue them in FIFO fashion
> (which is what I need). BUT: this is of course not optimal as it runs
> parallely with the server startup and I have to be carefull to  accomodate
> for that.
> 
> So, I'm all for reversing the logic of script execution i.e. doing the
> more natural way of runing them in FIFO fashion (now we have LIFO).
> But, I'm afraid of the potential compatibility problems. What I would
> like to see is if any of you would have objections to reversing the
> logic, and if yes, ideas how we could make this compatible?
> One idea would be:
> 
>    ns_atXXX ?-tail? $theScript
> 
> I'd rather go after FIFO list walk then adding yet-another-option,
> but I'm open to suggestions...
> 
> Cheers
> Zoran
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

[naviserver-devel] ns_cache

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

Stephen,

How is this going? Did you have any time to do some
work on your improvements to the caching code?

Cheers
Zoran

[naviserver-devel] ns_atstartup and order of execution?

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

Hi !

We have a pretty elaborate (and sometimes confusing) mechanism
for running various atXXX scripts.

So, if I would like to:

   ns_atstartup X
   ns_atstartup Y
   ns_atstartup Z

then the server will execute:

   Z
   Y
   X

i.e. in the *reverse* order. This is because all of those
are just entered in a single-linked list and the head of
the list points always to the *last* registered item.

This is suboptimal.

In many real world scenarios, I will like to use the ns_atstartup
to schedule couple of scripts to do various initialization things.
It is often so that Y will depend on X and Z on Y to be successfull.
At the moment, I'm (mis)using the ns_job with a single thread and
post the jobs there, because it will then exectue them in FIFO fashion
(which is what I need). BUT: this is of course not optimal as it runs
parallely with the server startup and I have to be carefull to  
accomodate
for that.

So, I'm all for reversing the logic of script execution i.e. doing the
more natural way of runing them in FIFO fashion (now we have LIFO).
But, I'm afraid of the potential compatibility problems. What I would
like to see is if any of you would have objections to reversing the
logic, and if yes, ideas how we could make this compatible?
One idea would be:

    ns_atXXX ?-tail? $theScript

I'd rather go after FIFO list walk then adding yet-another-option,
but I'm open to suggestions...

Cheers
Zoran

[naviserver-devel] ns_moduleload confusion?

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

Hi everybody!

The new ns_moduleload command seems to add some confusion
to what is being done on the virtual server/interp
initialization, unfortunately.

In the way it works now, modules are loaded from the
virtual server initialization script. At that time the new
ns_moduleload is used to load the module (and invoke its
Ns_ModuleInit call).

In the way it worked before, modules were loaded by the core
*before* the script got executed.

This has a very fine, yet problematic side effect (which is
BTW hitting  me very hard):

   If I place some Tcl commands in a module and would
   like to use those commands in the server init script
   I'm out of luck :-(

By coding my modules to use Ns_TclInitInterps() I was
simply adding a callback to be run each time an interp
was created for the thread. Now, during the startup when
the virtual server scripts are executed, the modules were
loaded by the server, and hence available in the interp
which was runnign the init script. This is  because a new
interp was created and inited before the script was run.

Now, the init script itself loads the module, the module does
register that callback but this is activated way later,
(for other interps, threads) hence my init scripts break.

I would not like to recompile all my modules. Even more,
it might be even impossible to do that because of the
existing field installations. So I have a serious backwards
compatibility problem.

Ah... just of curiousity, I inspected the nslog module and
there you go: the same thing is happening. This module
adds new Tcl command [ns_accesslog] which is inaccessible
during the evaluation of the virtual interp init script,
ALTHOUGH the module has been loaded with the ns_moduleload
BEFORE this command is used for the first time.

I believe we will have to reconsider the usage of ns_moduleload
mechanism ...

Otherwise, what are my options?

Cheers,
Zoran

Re: [naviserver-devel] command mode

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

Am 17.10.2005 um 13:19 schrieb Zoran Vasiljevic:

>
> Trouble is in ns/nslog.c... I will see why...
>

Ah... damn thing... It is my fault. I will fix this one in
next couple of minutes....

Zoran

Re: [naviserver-devel] command mode

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

Am 17.10.2005 um 13:12 schrieb Zoran Vasiljevic:
>
> I will look into that in more detail.


Trouble is in ns/nslog.c... I will see why...

Re: [naviserver-devel] Darwin DNS

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

On 10/17/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 17.10.2005 um 03:36 schrieb Stephen Deasey:
>
> > Why can't we fall back to using gethostbyname() on Darwin with it's
> > mt-unsafe getaddrinfo()?  gethostbyname() is also mt-unsafe, but we
> > already have a critical section around that.  If we have critical
> > sections around two separate dns calls which return the same results,
> > there's really no advantage in choosing one over the other, right?
> >
> >
>
> Hm... there IS a hidden one!
>
> Tcl core still uses MT-unsafe gethostbyname. If we'd to use the
> gethostbyname as well, no matter how protected we have made it
> within our process, the chances are we'd end up trampling on
> each other feet.
>
> On the short term I prefer this one. On the mid term I will replace
> the gethostbyname calls in Tcl core with something like dns.c in
> NS today.


Groovy.

Re: [naviserver-devel] command mode

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

Am 17.10.2005 um 12:54 schrieb Bernd Eidenschink:

>
> ah, "command mode" in my subject :-)
>
> It looks like starting the server with "-c" for command mode is  
> defunct in
> HEAD? Or did I just compile smth. wrong?
>

You are right. This breaks because isatty(0) returns false and
Tcl exits gracefully.
The offending code is burried somewhere in  NsInitServer(server,  
initProc)
line 674 in nsmain.c

I will look into that in more detail.

Zoran

Re: [naviserver-devel] command mode

[Bernd E. <eid...@we...>]

ah, "command mode" in my subject :-)

It looks like starting the server with "-c" for command mode is defunct in 
HEAD? Or did I just compile smth. wrong?

cu
Bernd.

[naviserver-devel] command mode

[Bernd E. <eid...@we...>]

Hi!

I just checked out the latest HEAD and gave autogen.sh a try. Works like a 
charm!
The VFS changes, logging of config parameters, ... - really great work from 
all you guys! So much for that :-)

cu
Bernd.

Re: [naviserver-devel] Ns_NormalizePath() broken?

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

Am 17.10.2005 um 03:54 schrieb Stephen Deasey:

> Are you sure Ns_NormalizePath() is broken?  I haven't examined it, but
> it's worth pointing out that it's most important use is normalizing
> the *URL path*, called early at the start of conn processing in
> request.c.
>
> The comment for Ns_NormalizePath() says "Assumes an absolute path",
> which seems reasonable when thinking about just URL paths.
>
> We need to figure out whether Ns_NormalizePath() really is broken and
> fix it, or otherwise resolve the confusion.
>
> Also, will [file normalize $path] do the right thing to a URL when
> used on Windows?

The main point is:

    ns_normalizepath

is used to normalize *what* paths?

The filesystem paths or URL paths?

If former, than it is broken since normalizing

    a/b

should not yield /a/b.

If latter, than it is merely a point of definition as in URL-space
there is nothing like the "current directory" concept.

The fact that ns_noramlizepath lived in tclfile.c leads me to conclude
that it is ment to be used on filesystem paths. What you're saying is
that it is primarily used to normalize URL paths. Well, we both may be
right or wrong, but this is a very good example of a poorly defined API.

Now, I would not like to leave "ns_normalizepath" as-is. It can very  
easily
make people think it can be used for filesystem paths (which it can't).
OTOH, replacing it with [file normalize] would hit anybody doing URL  
path
operations (I did't think of that possibility, unfortunately).

So what are our options?

Add ns_normalizeurlpath and declare ns_normalizepath obsolete?
Add -file | -url options to ns_normalizepath?

Cheers
Zoran

Re: [naviserver-devel] Darwin DNS

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

Am 17.10.2005 um 03:36 schrieb Stephen Deasey:

> Why can't we fall back to using gethostbyname() on Darwin with it's
> mt-unsafe getaddrinfo()?  gethostbyname() is also mt-unsafe, but we
> already have a critical section around that.  If we have critical
> sections around two separate dns calls which return the same results,
> there's really no advantage in choosing one over the other, right?
>
>

Hm... there IS a hidden one!

Tcl core still uses MT-unsafe gethostbyname. If we'd to use the
gethostbyname as well, no matter how protected we have made it
within our process, the chances are we'd end up trampling on
each other feet.

On the short term I prefer this one. On the mid term I will replace
the gethostbyname calls in Tcl core with something like dns.c in
NS today.


Cheers
Zoran
  

[naviserver-devel] Ns_NormalizePath() broken?

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

Are you sure Ns_NormalizePath() is broken?  I haven't examined it, but
it's worth pointing out that it's most important use is normalizing
the *URL path*, called early at the start of conn processing in
request.c.

The comment for Ns_NormalizePath() says "Assumes an absolute path",
which seems reasonable when thinking about just URL paths.

We need to figure out whether Ns_NormalizePath() really is broken and
fix it, or otherwise resolve the confusion.

Also, will [file normalize $path] do the right thing to a URL when
used on Windows?



#
# ns_normalizepath --
#
#   Normalize the path. WATCH: this procedure is actually broken
#   because it will normalize "a/b/c" to "/a/b/c" which is WRONG.
#   This is because it mimics the broken Ns_NormalizePath C-API.
#
#   Please use Tcl [file normalize] instead. This always return
#   properly normalized absolute path, as expected.
#

proc ns_normalizepath {path} {
    if {[file pathtype $path] =3D=3D "relative"} {
        ns_log warning "normalizepath: $path; broken for relative paths"
        ns_log warning "normalizepath: use \[file normalize\] instead"
        set path /$path
    }
    file normalize $path
}

Re: [naviserver-devel] Darwin DNS

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

On 10/8/05, Zoran Vasiljevic <zv...@ar...> wrote:
> No luck: this (NetBSD) system does not have any MT-safe call.
> What I did:
>
> During the configure I emit the warning if compiling under Darwin.
>
> checking for getaddrinfo in -lsocket... no
> checking for getnameinfo in -lsocket... no
> checking for getaddrinfo... yes
> checking for getnameinfo... yes
> checking for gethostbyname_r... no
> checking for gethostbyaddr_r... no
> configure: WARNING: DNS queries will use non-threadsafe calls which
> could result in server instability
>
> In dns.c I added
>
> #ifdef __APPLE__
>     Ns_Cs cs;
>     Ns_CsEnter(&cs);
>     ...
>     Ns_CsLeave(&cs);
> #endif
>
> to cope with this *at least* within our own program. This does not
> guarantee that this is MT-safe because any of the rest of the
> system may call those calls anytime, hence we get problems anyways.



Why can't we fall back to using gethostbyname() on Darwin with it's
mt-unsafe getaddrinfo()?  gethostbyname() is also mt-unsafe, but we
already have a critical section around that.  If we have critical
sections around two separate dns calls which return the same results,
there's really no advantage in choosing one over the other, right?

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.

[Re: Re: [naviserver-devel] Before I check in]

[<vl...@cr...>]

<p>Guy, I am out of country till Oct 18, so do not ex
pect anything from me, decide for yourself.</p><p>I am
 glad naviserver is still active, it was very quiet for the last couple of month
s.</p><p>-------- Original Message --------<br />To
: nav
ise...@li...<br />From: Zoran Vasiljevic <br />S
ubject: Re: [naviserver-devel] Before I check in<
br /><
br /><br />Am 05.10.2005 um 20:07 schrieb Stephen Deasey: <br /><br />&gt; I
 wonder if some will also need to look for global variables, to 
<br />
&gt; 
check
l for module version or something...? <br />&gt; <br />&gt; Any
way, if Tcl implements simillar functionality, we can just mig
rate <br />&gt; to the standard Tcl way of doing things. No
 need to wrap <br />&gt; <br /><br /><br />Tcl_FSLoadFile 
will allow you to checkup up to two sy
mbols
 <br />while loading the shared file. Among others it also
 loads <br />the 
share
d-lib or a bundle (mac osx beast) in one shot <br />from 
the file or fro
m mem
ory. I use 
this in mo
dload
.c <b
r />as the sole load/lookup function. <br /><br />If everybo
dy would use Ns_ModuleLoad, then we nee
d no <br />other calls. <br /><br />OK, so I will scrap the mentioned calls ou
t of the + <br />pubic API. <br /><br />Cheers <br />Zoran
 <br /><br /><br />---------------------------------
---------------------- <br />This 
SF.Net email is sponsored by: <br />Power A
rchitecture Resource Center: Free content, downloads, discussions,
 <br />a

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

[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] Darwin DNS

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

Am 08.10.2005 um 23:22 schrieb Stephen Deasey:

>
> This doesn't seem to work on my Linux system (Fedora Core 4):
>
> dns.c: In function 'GetHost':
> dns.c:264: error: 'struct sockaddr_in' has no member named 'sin_len'
>

Rats!

This is absolutely bad.
I recon we'D have to make something ugly as:

#ifdef __APPLE__
     static Ns_Cs cs;
     Ns_CsEnter(&cs);
     memset(&sa, 0, sizeof(struct sockaddr_in));
     sa.sin_family = AF_INET;
     sa.sin_len = sizeof(struct sockaddr_in);
#else
     memset(&sa, 0, sizeof(struct sockaddr_in));
     sa.sin_family = AF_INET;
#endif


W/o this explicit sin_len setup, the thing is just not
working on Darwin...

Should I check this in?
BTW: it is the latest 10.4.2 Darwin release.

Zoran

Re: [naviserver-devel] Darwin DNS

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

On 10/8/05, Zoran Vasiljevic <zv...@ar...> wrote:
> No luck: this (NetBSD) system does not have any MT-safe call.
> What I did:
>
> During the configure I emit the warning if compiling under Darwin.
>
> checking for getaddrinfo in -lsocket... no
> checking for getnameinfo in -lsocket... no
> checking for getaddrinfo... yes
> checking for getnameinfo... yes
> checking for gethostbyname_r... no
> checking for gethostbyaddr_r... no
> configure: WARNING: DNS queries will use non-threadsafe calls which
> could result in server instability
>
> In dns.c I added
>
> #ifdef __APPLE__
>     Ns_Cs cs;
>     Ns_CsEnter(&cs);
>     ...
>     Ns_CsLeave(&cs);
> #endif
>
> to cope with this *at least* within our own program. This does not
> guarantee that this is MT-safe because any of the rest of the
> system may call those calls anytime, hence we get problems anyways.


btw. is this the case with the latest OSX release?  I seem to remember
they updated the unix stuff, replacing a lot of the original NetBSD
infrastructure with newer FreeBSD.  Maybe the answer is to only
support OSX >=3D 10.x, is that's possible...?

Re: [naviserver-devel] Darwin DNS

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

On 10/8/05, Zoran Vasiljevic <zv...@ar...> wrote:
> No luck: this (NetBSD) system does not have any MT-safe call.
> What I did:
>
> During the configure I emit the warning if compiling under Darwin.
>
> checking for getaddrinfo in -lsocket... no
> checking for getnameinfo in -lsocket... no
> checking for getaddrinfo... yes
> checking for getnameinfo... yes
> checking for gethostbyname_r... no
> checking for gethostbyaddr_r... no
> configure: WARNING: DNS queries will use non-threadsafe calls which
> could result in server instability
>
> In dns.c I added
>
> #ifdef __APPLE__
>     Ns_Cs cs;
>     Ns_CsEnter(&cs);
>     ...
>     Ns_CsLeave(&cs);
> #endif
>
> to cope with this *at least* within our own program. This does not
> guarantee that this is MT-safe because any of the rest of the
> system may call those calls anytime, hence we get problems anyways.


This doesn't seem to work on my Linux system (Fedora Core 4):

dns.c: In function 'GetHost':
dns.c:264: error: 'struct sockaddr_in' has no member named 'sin_len'

[naviserver-devel] vfs changes applied

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

Hi!

I have applied the TclVFS changes to the CVS tree.
The previous state is tagged as "before-tclvfs"
if you need to wholesale backoff the changes for
some reason.

I have tried (my best) to locate all possible uses
of OS file-related calls and re-writte them with
Tcl_FS counterparts.

Exceptions are: log.c, tclfile.c and nslog/nslog.c
where this was not possible due to interdependence
of channels and threads in Tcl.

Special cases are: adpeval.c, adpreqest.c, fastpath.c
and urlopen.c. I have followed different logic there.
First, the OS call is applied (access, stat, open, read,
write etc). If this call failed, the Tcl_FS conunterpart
is applied. If this also failed, the error is thrown.
This way the VFS is second-class citizen in parts sensible
to performance. I'm pretty sure that you will not hit any
performance problem this way.

The modload.c is entirely rewritten to utilitze Tcl_FSLoadFile
which is *very* clever beast. As a side-effect, some public
C-API calls have been removed, while obsolete (I already
reported that in one of my previous email).

Please test the new code and if you find something awkward,
tell me immediately so I can fix it.

 From this point, NS should be able to serve pages from
any Tcl_VFS compatible filesystem. Moreover, it should be
capable of starting out of starpack, etc... This is STILL NOT
supported NOR tested, but I will soon get this done as well.

My target is to be able to wrap-up a distribution consisting
of a single executable file containing all the shared libs
and data needed to run a web-site and/or application.

Cheers
Zoran