naviserver-devel — Developer discussion

[naviserver-devel] 2 months have passed

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

Dear friends,

Well, exactly 2 months we started the project. A quick glance in the 
ChangeLog
reveals our current progress which is absolutely fantastic.
I'm proud to be a part of the team.

Zoran

Re: [naviserver-devel] Re: [naviserver-commits] naviserver/nsd dns.c,1.1.1.1,1.2

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

On 4/11/05, Zoran Vasiljevic <zv...@ar...> wrote:
>=20
> Am 11.04.2005 um 05:05 schrieb Stephen Deasey:
>=20
> > I guess this is an OSX problem?  While looking at the configure tests,
> > I noticed that gethostbyname_r etc. are not used on Linux, even though
> > they're available.  The standard call is thread safe, but only because
> > glibc puts a lock around everything.
> >
> > I wonder if for performance the *_r variants should always be
> > preferred...?
> >
>=20
> Actually, this happens only on Solaris 2.6 (yes, we still must support
> 2.6). No, the performance isn't the main reason. The main reason is
> other code using the non-mt-code. We can't just lock the call ourselves.
> We could do that if we were sitting in the libc, but we are not.
>=20
> Besides, this is/was a bug.


GETHOSTBYADDR_R isn't set when building on Linux, even though that
function is available.  The non-_r version is thread safe, as glibc
does the locking.  It will just serialize all calls and be slower.

It completely doesn't matter because getnameinfo is used in preference...  =
:-)

Re: [naviserver-devel] Current Status

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

Am 11.04.2005 um 05:00 schrieb Stephen Deasey:

> I was hoping to make a release now-ish, mainly because I think the
> cache and protocols stuff will be a little more destabilizing than the
> changes made so far.  It would simply provide a somewhat stable
> baseline for use/testing while HEAD moves on.
>
> I was going to call it 4.99.0, I wasn't going to make any public
> announcements to Freshmeat or anything.  A tarball would be cut and
> added to the file downloads section.  CVS would be tagged.  How about
> it?
>
> Regarding a final release, I agree a lot more needs to be done.  The
> protocols stuff would be a defining feature.  Docs are required.  If
> we want other people to use it some kind of website will be needed,
> too.  I don't know how long any of this will take.
>
> Periodic snapshots seem like a good idea.
>

OK. the only thing I'm afraid of is to support branches.
At the moment it does not matter since we're the only ones
using the beast. But, if you get other people on the wagon
you must then take this maintenance burden.
So, my reasoning was to get a feature-loaded state where
we can sit on for some more time. But, as said, for our
private use, I personally do not care much, as long as we
have a working head.

One reason for the release would be of course a stable
known state leaving the head branch for some interesting
testing...

Well, if you like... go and make the release. I believe the
CVS is in a good state now.

Zoran

Re: [naviserver-devel] Current Status

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

> 
> Regarding a final release, I agree a lot more needs to be done.  The
> protocols stuff would be a defining feature.  Docs are required.  If
> we want other people to use it some kind of website will be needed,
> too.  I don't know how long any of this will take.

Also virtual hosting support will be a huge difference putting NS almost 
on the same level as Apache.

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

Re: [naviserver-devel] Current Status

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

Stephen Deasey wrote:
> I was hoping to make a release now-ish, mainly because I think the
> cache and protocols stuff will be a little more destabilizing than the
> changes made so far.  It would simply provide a somewhat stable
> baseline for use/testing while HEAD moves on.

This is what i thought as well

> I was going to call it 4.99.0, I wasn't going to make any public
> announcements to Freshmeat or anything.  A tarball would be cut and
> added to the file downloads section.  CVS would be tagged.  How about
> it?


Yes, not public release, more like development

> Regarding a final release, I agree a lot more needs to be done.  The
> protocols stuff would be a defining feature.  Docs are required.  If
> we want other people to use it some kind of website will be needed,
> too.  I don't know how long any of this will take.

I am not rushing either, just to see what everybody thinks about it

> 
> 
> On Apr 10, 2005 3:58 AM, Zoran Vasiljevic <zv...@ar...> wrote:
> 
>>Am 10.04.2005 um 03:05 schrieb Vlad Seryakov:
>>
>>
>>>Do we have any plans to release Naviserver?
>>>
>>>IMHO, we still need to resolve nscache, virtual and protocol RFEs but
>>>even without them Naviserver is very and looks much better than AS
>>>already.
>>>Not that i am competing but i am switching to NS whenever possible
>>>already and what can be better proof than that :-))
>>>
>>>I am glad that i am on that project with you guys.
>>
>>Hey, not that fast. I do not think it is necessary to hurry at this
>>moment.
>>I would really consider having (whatever) multiprotocol support, nscache
>>and (perhaps) ttrace accepted and loaded. We are still using the AS for
>>the
>>product that we ship and I have yet to verify that all is working fine
>>with
>>the NS as well.
>>
>>The other issue is the documentation. I'm in contact with Andreas
>>Kupries
>>from the Tcl project who wrote doctools. I would like to make him do
>>some
>>changes to doctools so we can get a nice-looking man-pages as Tcl
>>project
>>has. If you look at, for example, "man Tcl_GetStringResult" this is the
>>output I'm heading at.
>>Doctools are very good for documenting Tcl code. There is nothing to be
>>done extra there. The entire tcllib is documented with doctools. There
>>is
>>however a problem when you like to document C-level code this way. You
>>can
>>do it on per-call basis, so each C-function receives a special manpage,
>>but
>>I'd like to have this improved and be able to document many calls
>>withing
>>one manpage as usually done elsewhere. At this point, doctools still
>>would
>>need some changes.
>>After this question (doctools yes/no and if not, then what) is resolved
>>I
>>could start collecting what's outthere in respect to the documentation.
>>I see this as a very important step since we've been doing functional
>>additions
>>on a weekly basis. It will slip out of the control and we will not know
>>what
>>is already in the code after some time. Therefore I consider having
>>(anykind of)
>>docs very important.
>>
>>Zoran
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> 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] Re: [naviserver-commits] naviserver/nsd dns.c,1.1.1.1,1.2

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

Am 11.04.2005 um 05:05 schrieb Stephen Deasey:

> I guess this is an OSX problem?  While looking at the configure tests,
> I noticed that gethostbyname_r etc. are not used on Linux, even though
> they're available.  The standard call is thread safe, but only because
> glibc puts a lock around everything.
>
> I wonder if for performance the *_r variants should always be 
> preferred...?
>

Actually, this happens only on Solaris 2.6 (yes, we still must support
2.6). No, the performance isn't the main reason. The main reason is
other code using the non-mt-code. We can't just lock the call ourselves.
We could do that if we were sitting in the libc, but we are not.

Besides, this is/was a bug.

Zoran

[naviserver-devel] Re: [naviserver-commits] naviserver/nsd dns.c,1.1.1.1,1.2

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

I guess this is an OSX problem?  While looking at the configure tests,
I noticed that gethostbyname_r etc. are not used on Linux, even though
they're available.  The standard call is thread safe, but only because
glibc puts a lock around everything.

I wonder if for performance the *_r variants should always be preferred...?



On Apr 9, 2005 3:16 AM, Zoran Vasiljevic
<vas...@us...> wrote:
> Update of /cvsroot/naviserver/naviserver/nsd
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21706
> 
> Modified Files:
>         dns.c
> Log Message:
> Fixed GetAddr when dealing with gethostbyname_r calls. In some cases
> we ended up in an infinite loop.
> 
> Index: dns.c
> ===================================================================
> RCS file: /cvsroot/naviserver/naviserver/nsd/dns.c,v
> retrieving revision 1.1.1.1
> retrieving revision 1.2
> diff -C2 -d -r1.1.1.1 -r1.2
> *** dns.c       16 Feb 2005 08:39:25 -0000      1.1.1.1
> --- dns.c       9 Apr 2005 09:16:15 -0000       1.2
> ***************
> *** 1,7 ****
>   /*
> !  * The contents of this file are subject to the AOLserver Public License
>    * Version 1.1 (the "License"); you may not use this file except in
>    * compliance with the License. You may obtain a copy of the License at
> !  * http://aolserver.com/.
>    *
>    * Software distributed under the License is distributed on an "AS IS"
> --- 1,7 ----
>   /*
> !  * The contents of this file are subject to the Mozilla Public License
>    * Version 1.1 (the "License"); you may not use this file except in
>    * compliance with the License. You may obtain a copy of the License at
> !  * http://mozilla.org/.
>    *
>    * Software distributed under the License is distributed on an "AS IS"
> ***************
> *** 347,354 ****
>               Tcl_DStringAppendElement(dsPtr, ns_inet_ntoa(
>                           ((struct sockaddr_in *) ptr->ai_addr)->sin_addr));
>               ptr = ptr->ai_next;
>           }
>           freeaddrinfo(res);
> -         status = NS_TRUE;
>       }
>       return status;
> --- 347,354 ----
>               Tcl_DStringAppendElement(dsPtr, ns_inet_ntoa(
>                           ((struct sockaddr_in *) ptr->ai_addr)->sin_addr));
> +             status = NS_TRUE;
>               ptr = ptr->ai_next;
>           }
>           freeaddrinfo(res);
>       }
>       return status;
> ***************
> *** 367,374 ****
>       char buf[2048];
>       int result;
> -     int i = 0;
>       int h_errnop;
>       int status = NS_FALSE;
> 
>   #if defined(HAVE_GETHOSTBYNAME_R_6)
>       result = gethostbyname_r(host, &he, buf, sizeof(buf), &res, &h_errnop);
> --- 367,375 ----
>       char buf[2048];
>       int result;
>       int h_errnop;
>       int status = NS_FALSE;
> 
> +     memset(buf, 0, sizeof(buf));
> +
>   #if defined(HAVE_GETHOSTBYNAME_R_6)
>       result = gethostbyname_r(host, &he, buf, sizeof(buf), &res, &h_errnop);
> ***************
> *** 385,389 ****
> 
>       if (result != 0) {
> !       LogError("gethostbyname_r", h_errnop);
>       } else {
>           ptr = (struct in_addr *) he.h_addr_list[i];
> --- 386,390 ----
> 
>       if (result != 0) {
> !         LogError("gethostbyname_r", h_errnop);
>       } else {
>           ptr = (struct in_addr *) he.h_addr_list[i];
> ***************
> *** 392,395 ****
> --- 393,397 ----
>               Tcl_DStringAppendElement(dsPtr, ns_inet_ntoa(ia));
>               status = NS_TRUE;
> +             ptr = (struct in_addr *) he.h_addr_list[++i];
>           }
>       }
> ***************
> *** 419,423 ****
>       he = gethostbyname(host);
>       if (he == NULL) {
> !       LogError("gethostbyname", h_errno);
>       } else {
>           ptr = (struct in_addr *) he.h_addr_list[i];
> --- 421,425 ----
>       he = gethostbyname(host);
>       if (he == NULL) {
> !         LogError("gethostbyname", h_errno);
>       } else {
>           ptr = (struct in_addr *) he.h_addr_list[i];
> ***************
> *** 426,429 ****
> --- 428,432 ----
>               Tcl_DStringAppendElement(dsPtr, ns_inet_ntoa(ia));
>               status = NS_TRUE;
> +             ptr = (struct in_addr *) he.h_addr_list[++i];
>           }
>       }
>

Re: [naviserver-devel] Current Status

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

I was hoping to make a release now-ish, mainly because I think the
cache and protocols stuff will be a little more destabilizing than the
changes made so far.  It would simply provide a somewhat stable
baseline for use/testing while HEAD moves on.

I was going to call it 4.99.0, I wasn't going to make any public
announcements to Freshmeat or anything.  A tarball would be cut and
added to the file downloads section.  CVS would be tagged.  How about
it?

Regarding a final release, I agree a lot more needs to be done.  The
protocols stuff would be a defining feature.  Docs are required.  If
we want other people to use it some kind of website will be needed,
too.  I don't know how long any of this will take.

Periodic snapshots seem like a good idea.



On Apr 10, 2005 3:58 AM, Zoran Vasiljevic <zv...@ar...> wrote:
> 
> Am 10.04.2005 um 03:05 schrieb Vlad Seryakov:
> 
> > Do we have any plans to release Naviserver?
> >
> > IMHO, we still need to resolve nscache, virtual and protocol RFEs but
> > even without them Naviserver is very and looks much better than AS
> > already.
> > Not that i am competing but i am switching to NS whenever possible
> > already and what can be better proof than that :-))
> >
> > I am glad that i am on that project with you guys.
> 
> Hey, not that fast. I do not think it is necessary to hurry at this
> moment.
> I would really consider having (whatever) multiprotocol support, nscache
> and (perhaps) ttrace accepted and loaded. We are still using the AS for
> the
> product that we ship and I have yet to verify that all is working fine
> with
> the NS as well.
> 
> The other issue is the documentation. I'm in contact with Andreas
> Kupries
> from the Tcl project who wrote doctools. I would like to make him do
> some
> changes to doctools so we can get a nice-looking man-pages as Tcl
> project
> has. If you look at, for example, "man Tcl_GetStringResult" this is the
> output I'm heading at.
> Doctools are very good for documenting Tcl code. There is nothing to be
> done extra there. The entire tcllib is documented with doctools. There
> is
> however a problem when you like to document C-level code this way. You
> can
> do it on per-call basis, so each C-function receives a special manpage,
> but
> I'd like to have this improved and be able to document many calls
> withing
> one manpage as usually done elsewhere. At this point, doctools still
> would
> need some changes.
> After this question (doctools yes/no and if not, then what) is resolved
> I
> could start collecting what's outthere in respect to the documentation.
> I see this as a very important step since we've been doing functional
> additions
> on a weekly basis. It will slip out of the control and we will not know
> what
> is already in the code after some time. Therefore I consider having
> (anykind of)
> docs very important.
> 
> Zoran

Re: [naviserver-devel] Server command line

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

On Apr 9, 2005 10:39 AM, Zoran Vasiljevic <zv...@ar...> wrote:
>  
> zvpb:~/sf/naviserver/nsd zoran$ ./nsd -V
> NaviServer/4.0.10 (naviserver4_0)
>     CVS Tag:         $Name:  $
>     Built:           Apr  9 2005 at 18:34:07
>     Tcl version:     8.4
>     Platform:        osx

nsd/nsd.h:

/*
 * constants
 */

#define NSD_NAME             "NaviServer"
#define NSD_VERSION	     NS_PATCH_LEVEL
#define NSD_LABEL            "naviserver4_0"
#define NSD_TAG              "$Name:  $"


Looks like NSD_LABEL is just a manually maintained (out of date)
version of NSD_TAG also available via Ns_InfoLabel().

Junk it and just use NSD_TAG?

Re: [naviserver-devel] Current Status

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

Am 10.04.2005 um 03:05 schrieb Vlad Seryakov:

> Do we have any plans to release Naviserver?
>
> IMHO, we still need to resolve nscache, virtual and protocol RFEs but 
> even without them Naviserver is very and looks much better than AS 
> already.
> Not that i am competing but i am switching to NS whenever possible 
> already and what can be better proof than that :-))
>
> I am glad that i am on that project with you guys.

Hey, not that fast. I do not think it is necessary to hurry at this 
moment.
I would really consider having (whatever) multiprotocol support, nscache
and (perhaps) ttrace accepted and loaded. We are still using the AS for 
the
product that we ship and I have yet to verify that all is working fine 
with
the NS as well.

The other issue is the documentation. I'm in contact with Andreas 
Kupries
from the Tcl project who wrote doctools. I would like to make him do 
some
changes to doctools so we can get a nice-looking man-pages as Tcl 
project
has. If you look at, for example, "man Tcl_GetStringResult" this is the
output I'm heading at.
Doctools are very good for documenting Tcl code. There is nothing to be
done extra there. The entire tcllib is documented with doctools. There 
is
however a problem when you like to document C-level code this way. You 
can
do it on per-call basis, so each C-function receives a special manpage, 
but
I'd like to have this improved and be able to document many calls 
withing
one manpage as usually done elsewhere. At this point, doctools still 
would
need some changes.
After this question (doctools yes/no and if not, then what) is resolved 
I
could start collecting what's outthere in respect to the documentation.
I see this as a very important step since we've been doing functional 
additions
on a weekly basis. It will slip out of the control and we will not know 
what
is already in the code after some time. Therefore I consider having 
(anykind of)
docs very important.

Zoran

[naviserver-devel] Current Status

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

Do we have any plans to release Naviserver?

IMHO, we still need to resolve nscache, virtual and protocol RFEs but 
even without them Naviserver is very and looks much better than AS already.
Not that i am competing but i am switching to NS whenever possible 
already and what can be better proof than that :-))

I am glad that i am on that project with you guys.

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

Re: [naviserver-devel] ns_parseargs segv

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

And now my sendmail arguments do not crash NS either, so it might be fixed.

Zoran Vasiljevic wrote:
> 
> Am 09.04.2005 um 19:45 schrieb Stephen Deasey:
> 
>> Take a look at tclobj.c: SetTimeInternalRep() -- it also invalidates
>> it's string rep.  I wonder why this has never shown up as an error...?
>>
>>
> I've seen that allright.  To be honest, I do not follow this
> but I found out if you do
> 
>   set opts "-a"
>   ns_parseargs $opts ""
> 
> it does not core. Then I looked into the TclDeleteLiteralTable
> and saw that they really do need to get internal string rep
> of the object for some strange lookups. So, I reasoned that
> if you *only* convert the internal rep, the string rep should
> not actually change. Therefore it  *might* not be neccessary
> to trash it. By *virtualy* conecting those two facts, I decided
> to give it a try *without* trashing the string rep and it worked
> fine. So, if you need a very precise answer at the moment, I can't
> give it. I'd need to dig it even more. But since it seems to work
> now as-is, I'd leave it so.
> 
> Zoran
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> 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_parseargs segv

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

Am 09.04.2005 um 19:45 schrieb Stephen Deasey:

> Take a look at tclobj.c: SetTimeInternalRep() -- it also invalidates
> it's string rep.  I wonder why this has never shown up as an error...?
>
>
I've seen that allright.  To be honest, I do not follow this
but I found out if you do

   set opts "-a"
   ns_parseargs $opts ""

it does not core. Then I looked into the TclDeleteLiteralTable
and saw that they really do need to get internal string rep
of the object for some strange lookups. So, I reasoned that
if you *only* convert the internal rep, the string rep should
not actually change. Therefore it  *might* not be neccessary
to trash it. By *virtualy* conecting those two facts, I decided
to give it a try *without* trashing the string rep and it worked
fine. So, if you need a very precise answer at the moment, I can't
give it. I'd need to dig it even more. But since it seems to work
now as-is, I'd leave it so.

Zoran

Re: [naviserver-devel] ns_parseargs segv

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

On Apr 9, 2005 8:36 AM, Zoran Vasiljevic <zv...@ar...> wrote:
> 
> Am 04.04.2005 um 03:16 schrieb Stephen Deasey:
> 
> > I haven't figured this out yet :-(
> > It's probably going to be next week before I can take another look.
> >
> >
> 
> Hmmm... just went on Purify trip and unfortunately no cigar.
> But...
> 
> I was experimenting somehow, and looking parallel into some
> of our code and Tcl's code about obj handling.
> There are two places I found:
> 
> RCS file: /cvsroot/naviserver/naviserver/nsd/tclobj.c,v
> retrieving revision 1.2
> diff -r1.2 tclobj.c
> 123c123
> <         (typePtr->freeIntRepProc)(objPtr);
> ---
>  >         (*typePtr->freeIntRepProc)(objPtr);
> 
> I wonder how this *ever* worked before? I doubt
> that anybody seriously used that.


I think these two are equivalent, but only because they're function
pointers.  The dereferencing style is consistent with the rest of the
source though.


> Another thing: I do not think you should free the string rep
> of the object by just calling the Tcl_ConvertToType (which
> eventually calls SetSpecFromAny()). I modified the SetSpecFromAny()
> to skip forcefully invalidating the string rep and now it works.


Hmm, I think I added that to force a canonicalisation of the string
rep, but it doesn't seem necessary (to say the least!).

Take a look at tclobj.c: SetTimeInternalRep() -- it also invalidates
it's string rep.  I wonder why this has never shown up as an error...?


> Also, in FreeSpecObj, it is necessary to zero-out the ptr1/ptr2
> after freeing them since this will bring up the real problem sooner
> on the surface. Besides, it is also cleaner.
> 
> I've checked those changes. Please have a look and see if this
> is OK for you.


Tests pass for me.  Thanks!

Re: [naviserver-devel] Server command line

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

Am 09.04.2005 um 19:26 schrieb Stephen Deasey:

> I think this only works when you 'cvs tag MYTAG' and then 'cvs export
> -r MYTAG'.  If you're always working off HEAD, you'll never see
> anything useful here.
>
> Just wait for the first glorious release!
>

Ah... I did not think about that. This can be true.
Thanks for the clarification.
Zoran

Re: [naviserver-devel] Server command line

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

On Apr 9, 2005 10:13 AM, Zoran Vasiljevic <zv...@ar...> wrote:
> Hm...
> 
> Error: required -t <config> option not specified
> 
> Usage: bin/nsd [-h|V] [-c|-i|f] [-u <user>] [-g <group>] [-r <path>]
> [-b <address:port>|-B <file>] [-s <server>] -t <file>
> 
> This ain't very important but the syntax of the command line
> *should* have been something like this:
> 
> Usage: bin/nsd [-h|V] [-c|-i|f] [-u <user>] [-g <group>] [-r <path>]
> [-b <address:port>|-B <file>] [-s <server>] <file>
> 
> I do not understand why on earth the "-t" option is "option" and
> "required" ?
> Generally speaking,
> 
>    nsd [options] <config.file>
> 
> would seem much more logical to me.


Don't think of it as an option, it's a named argument...  :-)

It made sense when there was two types of config files: windows-style
ini or new-style tcl.  The ini files have bee dropped and now it does
seem a little weird.  Oh well...

Re: [naviserver-devel] Server command line

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

I think this only works when you 'cvs tag MYTAG' and then 'cvs export
-r MYTAG'.  If you're always working off HEAD, you'll never see
anything useful here.

Just wait for the first glorious release!



On Apr 9, 2005 10:39 AM, Zoran Vasiljevic <zv...@ar...> wrote:
> 
> Am 09.04.2005 um 18:13 schrieb Zoran Vasiljevic:
> 
> > Hm...
> >
> 
> more hmmmm's...
> 
> zvpb:~/sf/naviserver/nsd zoran$ ./nsd -V
> NaviServer/4.0.10 (naviserver4_0)
>     CVS Tag:         $Name:  $
>     Built:           Apr  9 2005 at 18:34:07
>     Tcl version:     8.4
>     Platform:        osx
> 
> Did anyone *ever* got CVS Tag correctly substituted/displayed?
> I did't. Is there any magic there I should be aware of?
> 
> Zoran
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] Server command line

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

Am 09.04.2005 um 18:13 schrieb Zoran Vasiljevic:

> Hm...
>

more hmmmm's...

zvpb:~/sf/naviserver/nsd zoran$ ./nsd -V
NaviServer/4.0.10 (naviserver4_0)
    CVS Tag:         $Name:  $
    Built:           Apr  9 2005 at 18:34:07
    Tcl version:     8.4
    Platform:        osx

Did anyone *ever* got CVS Tag correctly substituted/displayed?
I did't. Is there any magic there I should be aware of?

Zoran

[naviserver-devel] Server command line

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

Hm...

Error: required -t <config> option not specified

Usage: bin/nsd [-h|V] [-c|-i|f] [-u <user>] [-g <group>] [-r <path>] 
[-b <address:port>|-B <file>] [-s <server>] -t <file>

This ain't very important but the syntax of the command line
*should* have been something like this:

Usage: bin/nsd [-h|V] [-c|-i|f] [-u <user>] [-g <group>] [-r <path>] 
[-b <address:port>|-B <file>] [-s <server>] <file>

I do not understand why on earth the "-t" option is "option" and 
"required" ?
Generally speaking,

   nsd [options] <config.file>

would seem much more logical to me.

Zoran

Re: [naviserver-devel] ns_parseargs segv

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

Am 04.04.2005 um 03:16 schrieb Stephen Deasey:

> I haven't figured this out yet :-(
> It's probably going to be next week before I can take another look.
>
>

Hmmm... just went on Purify trip and unfortunately no cigar.
But...

I was experimenting somehow, and looking parallel into some
of our code and Tcl's code about obj handling.
There are two places I found:

RCS file: /cvsroot/naviserver/naviserver/nsd/tclobj.c,v
retrieving revision 1.2
diff -r1.2 tclobj.c
123c123
<         (typePtr->freeIntRepProc)(objPtr);
---
 >         (*typePtr->freeIntRepProc)(objPtr);

I wonder how this *ever* worked before? I doubt
that anybody seriously used that.

Another thing: I do not think you should free the string rep
of the object by just calling the Tcl_ConvertToType (which
eventually calls SetSpecFromAny()). I modified the SetSpecFromAny()
to skip forcefully invalidating the string rep and now it works.

Also, in FreeSpecObj, it is necessary to zero-out the ptr1/ptr2
after freeing them since this will bring up the real problem sooner
on the surface. Besides, it is also cleaner.

I've checked those changes. Please have a look and see if this
is OK for you.

Zoran

Re: [naviserver-devel] Leak (quasi) in Tcl memory allocator

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

It looks like ns_job is what i need, thanks

Stephen Deasey wrote:
> On Apr 7, 2005 6:35 AM, Vlad Seryakov <vl...@cr...> wrote:
> 
>>i know about ns_job but never used it and never seen any examples how to
>>use it, it might be the solution, might be not
> 
> 
> It implements a thread pool, so if you're concerned about the costs of
> constantly creating new threads to perform work, I think this is what
> you're looking for.
> 
> There are a set of tests for ns_job that need modernized and added to
> our test suite. This might be a source of good examples:
> 
> http://cvs.sourceforge.net/viewcvs.py/aolserver/aolserver/tests/api/ns_job.adp?rev=1.5&view=markup
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> 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] Leak (quasi) in Tcl memory allocator

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

On Apr 7, 2005 6:35 AM, Vlad Seryakov <vl...@cr...> wrote:
> i know about ns_job but never used it and never seen any examples how to
> use it, it might be the solution, might be not

It implements a thread pool, so if you're concerned about the costs of
constantly creating new threads to perform work, I think this is what
you're looking for.

There are a set of tests for ns_job that need modernized and added to
our test suite. This might be a source of good examples:

http://cvs.sourceforge.net/viewcvs.py/aolserver/aolserver/tests/api/ns_job.adp?rev=1.5&view=markup

Re: [naviserver-devel] Leak (quasi) in Tcl memory allocator

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

On Apr 7, 2005 3:31 AM, Zoran Vasiljevic <zv...@ar...> wrote:
> 
> Am 06.04.2005 um 21:07 schrieb Stephen Deasey:
> 
> >    Correct threaded obj allocator to
> >     fully cleanup on exit and allow for
> >     reinitialization. [Bug #736426]
> >     (mistachkin, kenny)
> >
> 
> Rats. I know now where this comes from.


Great news!

Re: [naviserver-devel] Leak (quasi) in Tcl memory allocator

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

i know about ns_job but never used it and never seen any examples how to 
use it, it might be the solution, might be not

Stephen Deasey wrote:
> On Apr 6, 2005 1:43 PM, Vlad Seryakov <vl...@cr...> wrote:
> 
>>Oh, yes, i remember read something about that, i am actually using up to
>>100 threads at the same time and they are created/exit all the time.
>>That was one of my intentions to be able to submit data to conn thread
>>to minimize thread creation instead of introducing new thread pooling
>>manager.
> 
> 
> 
> ns_job?
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> 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] Leak (quasi) in Tcl memory allocator

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

Am 06.04.2005 um 21:07 schrieb Stephen Deasey:

>    Correct threaded obj allocator to
>     fully cleanup on exit and allow for
>     reinitialization. [Bug #736426]
>     (mistachkin, kenny)
>

Rats. I know now where this comes from. Joe Mistachkin
was at the hunt of things to destroy on Tcl_Finalize()
in order to make the clean Tcl library unload.
Basically this is OK.  Well, at that point he was
little bit too agressive...

He just blew the entire tsd-specific key every time
a thread exited. Actually, this should have been done
only once and that is when the Tcl_Finalize() has been called.

Heck.. I'd have to fix this in Tcl project...

Zoran