naviserver-devel — Developer discussion

Re: [naviserver-devel] nacache

[Andrew P. <at...@pi...>]

On Thu, Dec 29, 2005 at 07:11:35PM -0700, Stephen Deasey wrote:

> Still to think about are per-thread Tcl caches.  The main reason for
> these are that you can put Tcl objects in the cache, not just their
> string rep, which is particularly useful for already-compiled byte
> code -- i.e. for *.tcl pages.

Tcl code in *.tcl pages (not in procs) can be, has been, and I hope
currently still is cached in OpenACS using the mechanism Rob Mayoff
added to AOLserver 3.3 long ago.  Essentially, all Tcl code in each
*.tcl page is automatically "compiled" to Tcl procs on first
execution, and those procs' bytecode is then cached via ns_cache.
Each connection thread does its own entirely independent cacheing, but
it worked fine and apparently was a substantial speed up for some ACS
sites when switching from AOLserver 3.3+ad11 or 3.3+ad12 (I forget
which) to 3.3+ad13.

Actually, I'm not sure whether that code is currently active or not.
It sounds as if the feature may have broke during the AOLserver 3.x to
4.x transition and never been repaired.  See here for more info:

  http://sourceforge.net/tracker/?func=detail&aid=689515&group_id=3152&atid=353152

Does Rob's cacheing cover the functionality you want, or are you
thinking of cacheing of some other sort of Tcl objects?

> The best solution for caching byte code might be to share the
> mechanism with ADP pages.  They currently have a pre-thread cache of
> script blocks, and a per-server cache of text blocks, for each page. 
> AOLserver 4.5 adds a per-server output cache.  We could use this for
> *.tcl pages as well, perhaps negating the need for per-thread Tcl
> caches.  That still leaves Tcl objects like lists or dictionaries that
> you may not want to stringify on each access.

Ah.  I think Rob's code above solely cached compiled Tcl bytecode (in
what form I don't know), not Tcl_Obj representations of anything.
I've also no idea whether it plays nicely with Zoran's Ttrace
extension or not.

But, we already have centralized server-wide cacheing of Tcl_Obj's via
Zoran's Tcl Threads Extension, right?  So, is there any real use case
for a per-thread Tcl_Obj cache?  (Offhand I can't think of one, but
then I don't think I've ever really used ns_cache directly at all,
only the simplified util_memoize facility of OpenACS, so I'm not the
right person to ask.)

-- 
Andrew Piskorski <at...@pi...>
http://www.piskorski.com/

Re: [naviserver-devel] Naviserver and OACS (compatibility)?

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

Yes, i forgot about aolserver's way and people using it. So, now with 
your patch it works the same way as aolserver? Then keep it.

Stephen Deasey wrote:
> I'm all in favour of simplifying and clarifying, even when it means
> some work is required on existing code.  But in the case of filter
> proc arg ordering there doesn't seem to be a clean way to write code
> that will work on both AOLserver and NaviServer if the args are
> reversed.  Unless someone has any ideas..?
> 
> There are a few people now who've expressed interest in running
> OpenACS on NaviServer and I wouldn't want to break things
> gratuitously.  The more people testing the code the better!
> 
> 
> 
> On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> 
>>Between three of us do we have a lot of code that uses filter with
>>aolserver's style of argument ordering?
>>If none, then i do not see why we cannot change it. Compatibility with
>>weird aolserver things never been our primary goal:-))
>>
>>At least it will be one less confusing places in the code and API.
>>
>>Stephen Deasey wrote:
>>
>>>I added the comment because the argument order is confusing.  We could
>>>change the order, but it not be compatible with AOLserver.  Do large
>>>bodies of code such as OpenACS use filter args?  I think they do...
>>>
>>>
>>>Something we could change is registered procs.  Currently, an extra
>>>args is always passed to the registered proc (a blank string if you
>>>don't specify anything else).  Dropping this would be cleaner.  This
>>>is an incompatible change, but it's easy to write code that works on
>>>both AOLserver and NaviServer using defaults:
>>>
>>>    proc my_registered_proc {{context default}} { ... }
>>>    ns_register_proc GET /* my_registered_proc
>>>    ns_register_proc GET /* my_registered_proc my_context
>>>
>>>What do you think?
>>>
>>>
>>>On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
>>>
>>>
>>>>It still has this comment, so we can get rid of that comment and fix the
>>>>order at the same time:-))
>>>>
>>>>/*
>>>> * This really should be: cmd why ?arg?, but why and arg
>>>> * are reversed for backwards compatibility.
>>>> */
>>>>
>>>>
>>>>Stephen Deasey wrote:
>>>>
>>>>
>>>>>Fixed in CVS a couple of days ago.  My fault, I missread the original
>>>>>code and thought that like registered procs, if you didn't explicitly
>>>>>pass an arg a blank string was passed.  Should work now.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>It is in
>>>>>>
>>>>>>int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
>>>>>>
>>>>>>why arg is added after script args
>>>>>>
>>>>>>We can change it easily to always specify why first
>>>>>>
>>>>>>
>>>>>>Zoran Vasiljevic wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>ns_register_filter trace GET * myfilter
>>>>>>>>>>
>>>>>>>>>>calls now "myfilter {} WHY"
>>>>>>>
>>>>>>>
>>>>>>>But *why* is this so? IOW, what is this empty argument
>>>>>>>passed to the myfilter? Is this something we overlooked
>>>>>>>or is it something done on purpose, or what?
>>>>>>>
>>>>>>>I mean, maybe somebody has the answer out of the sleeve
>>>>>>>and if not, I will have to dig into that...
>>>>>>>
>>>>>>>Cheers
>>>>>>>Zoran
>>>>>>>
>>>>>>>
>>>>>>>-------------------------------------------------------
>>>>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>>>>>>files
>>>>>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>>>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&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/
>>>>>>
>>>>>>
>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>>>>_______________________________________________
>>>>>>naviserver-devel mailing list
>>>>>>nav...@li...
>>>>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>>>http://ads.osdn.com/?ad_idv37&alloc_id865&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/
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>>_______________________________________________
>>>>naviserver-devel mailing list
>>>>nav...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>http://ads.osdn.com/?ad_idv37&alloc_id865&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/
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>for problems?  Stop!  Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>_______________________________________________
>>naviserver-devel mailing list
>>nav...@li...
>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&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] Naviserver and OACS (compatibility)?

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

I'm all in favour of simplifying and clarifying, even when it means
some work is required on existing code.  But in the case of filter
proc arg ordering there doesn't seem to be a clean way to write code
that will work on both AOLserver and NaviServer if the args are
reversed.  Unless someone has any ideas..?

There are a few people now who've expressed interest in running
OpenACS on NaviServer and I wouldn't want to break things
gratuitously.  The more people testing the code the better!



On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> Between three of us do we have a lot of code that uses filter with
> aolserver's style of argument ordering?
> If none, then i do not see why we cannot change it. Compatibility with
> weird aolserver things never been our primary goal:-))
>
> At least it will be one less confusing places in the code and API.
>
> Stephen Deasey wrote:
> > I added the comment because the argument order is confusing.  We could
> > change the order, but it not be compatible with AOLserver.  Do large
> > bodies of code such as OpenACS use filter args?  I think they do...
> >
> >
> > Something we could change is registered procs.  Currently, an extra
> > args is always passed to the registered proc (a blank string if you
> > don't specify anything else).  Dropping this would be cleaner.  This
> > is an incompatible change, but it's easy to write code that works on
> > both AOLserver and NaviServer using defaults:
> >
> >     proc my_registered_proc {{context default}} { ... }
> >     ns_register_proc GET /* my_registered_proc
> >     ns_register_proc GET /* my_registered_proc my_context
> >
> > What do you think?
> >
> >
> > On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> >
> >>It still has this comment, so we can get rid of that comment and fix th=
e
> >>order at the same time:-))
> >>
> >>/*
> >>  * This really should be: cmd why ?arg?, but why and arg
> >>  * are reversed for backwards compatibility.
> >>  */
> >>
> >>
> >>Stephen Deasey wrote:
> >>
> >>>Fixed in CVS a couple of days ago.  My fault, I missread the original
> >>>code and thought that like registered procs, if you didn't explicitly
> >>>pass an arg a blank string was passed.  Should work now.
> >>>
> >>>
> >>>
> >>>
> >>>On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> >>>
> >>>
> >>>>It is in
> >>>>
> >>>>int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
> >>>>
> >>>>why arg is added after script args
> >>>>
> >>>>We can change it easily to always specify why first
> >>>>
> >>>>
> >>>>Zoran Vasiljevic wrote:
> >>>>
> >>>>
> >>>>>Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>ns_register_filter trace GET * myfilter
> >>>>>>>>
> >>>>>>>>calls now "myfilter {} WHY"
> >>>>>
> >>>>>
> >>>>>But *why* is this so? IOW, what is this empty argument
> >>>>>passed to the myfilter? Is this something we overlooked
> >>>>>or is it something done on purpose, or what?
> >>>>>
> >>>>>I mean, maybe somebody has the answer out of the sleeve
> >>>>>and if not, I will have to dig into that...
> >>>>>
> >>>>>Cheers
> >>>>>Zoran
> >>>>>
> >>>>>
> >>>>>-------------------------------------------------------
> >>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through l=
og
> >>>>>files
> >>>>>for problems?  Stop!  Download the new AJAX search engine that makes
> >>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLU=
NK!
> >>>>>http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> >>>>>_______________________________________________
> >>>>>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/
> >>>>
> >>>>
> >>>>
> >>>>-------------------------------------------------------
> >>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through lo=
g files
> >>>>for problems?  Stop!  Download the new AJAX search engine that makes
> >>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUN=
K!
> >>>>http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> >>>>_______________________________________________
> >>>>naviserver-devel mailing list
> >>>>nav...@li...
> >>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> >>>>
> >>>
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log=
 files
> >>>for problems?  Stop!  Download the new AJAX search engine that makes
> >>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK=
!
> >>>http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> >>>_______________________________________________
> >>>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/
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> >>for problems?  Stop!  Download the new AJAX search engine that makes
> >>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> >>http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> >>_______________________________________________
> >>naviserver-devel mailing list
> >>nav...@li...
> >>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> > _______________________________________________
> > 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/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] nacache

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

On 12/24/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 23.12.2005 um 20:03 schrieb Stephen Deasey:
>
> > Yes, good points.  I've uploaded a new patch which merges everything
> > into the core with minimal changes to existing C code.  Let me know
> > how this looks.
>
> Great!
>
> >
> > Regarding API compatibility for Tcl code, I thought a wrapper ns_cache
> > command could be added to the tcl/cache.tcl file.  What do you think?
>
> You mean "ns_cache eval" -> "ns_cache_eval" stuff? Yes, just place
> them there. There are not too many of them anyways.
> When I look thru our code, we just use ns_cache (create, eval, flush)
> so I will go and rename them to ns_cache_create etc.
>
> And, commit that code.


OK.  It shouldn't cause any problems with existing code, and you can
still load the nscache module, so I'll go ahead and we can see how it
works out.  It's only ~600 lines of code for the Tcl commands, and
~500 chopped out of cache.c, so I think it's going in the right
direction.

Still to think about are per-thread Tcl caches.  The main reason for
these are that you can put Tcl objects in the cache, not just their
string rep, which is particularly useful for already-compiled byte
code -- i.e. for *.tcl pages.

The best solution for caching byte code might be to share the
mechanism with ADP pages.  They currently have a pre-thread cache of
script blocks, and a per-server cache of text blocks, for each page.=20
AOLserver 4.5 adds a per-server output cache.  We could use this for
*.tcl pages as well, perhaps negating the need for per-thread Tcl
caches.  That still leaves Tcl objects like lists or dictionaries that
you may not want to stringify on each access.

Input welcome...

Re: [naviserver-devel] Naviserver and OACS (compatibility)?

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

Between three of us do we have a lot of code that uses filter with 
aolserver's style of argument ordering?
If none, then i do not see why we cannot change it. Compatibility with 
weird aolserver things never been our primary goal:-))

At least it will be one less confusing places in the code and API.

Stephen Deasey wrote:
> I added the comment because the argument order is confusing.  We could
> change the order, but it not be compatible with AOLserver.  Do large
> bodies of code such as OpenACS use filter args?  I think they do...
> 
> 
> Something we could change is registered procs.  Currently, an extra
> args is always passed to the registered proc (a blank string if you
> don't specify anything else).  Dropping this would be cleaner.  This
> is an incompatible change, but it's easy to write code that works on
> both AOLserver and NaviServer using defaults:
> 
>     proc my_registered_proc {{context default}} { ... }
>     ns_register_proc GET /* my_registered_proc
>     ns_register_proc GET /* my_registered_proc my_context
> 
> What do you think?
> 
> 
> On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> 
>>It still has this comment, so we can get rid of that comment and fix the
>>order at the same time:-))
>>
>>/*
>>  * This really should be: cmd why ?arg?, but why and arg
>>  * are reversed for backwards compatibility.
>>  */
>>
>>
>>Stephen Deasey wrote:
>>
>>>Fixed in CVS a couple of days ago.  My fault, I missread the original
>>>code and thought that like registered procs, if you didn't explicitly
>>>pass an arg a blank string was passed.  Should work now.
>>>
>>>
>>>
>>>
>>>On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
>>>
>>>
>>>>It is in
>>>>
>>>>int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
>>>>
>>>>why arg is added after script args
>>>>
>>>>We can change it easily to always specify why first
>>>>
>>>>
>>>>Zoran Vasiljevic wrote:
>>>>
>>>>
>>>>>Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
>>>>>
>>>>>
>>>>>
>>>>>>>>ns_register_filter trace GET * myfilter
>>>>>>>>
>>>>>>>>calls now "myfilter {} WHY"
>>>>>
>>>>>
>>>>>But *why* is this so? IOW, what is this empty argument
>>>>>passed to the myfilter? Is this something we overlooked
>>>>>or is it something done on purpose, or what?
>>>>>
>>>>>I mean, maybe somebody has the answer out of the sleeve
>>>>>and if not, I will have to dig into that...
>>>>>
>>>>>Cheers
>>>>>Zoran
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>>>>files
>>>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&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/
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>>>_______________________________________________
>>>>naviserver-devel mailing list
>>>>nav...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>http://ads.osdn.com/?ad_idv37&alloc_id865&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/
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>for problems?  Stop!  Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>_______________________________________________
>>naviserver-devel mailing list
>>nav...@li...
>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&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] happy christmas

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

On 12/24/05, Zoran Vasiljevic <zv...@ar...> wrote:
> To all of you dear friends.
> It was a very good year and it was a great
> pleasure to work with you.
>
> Cheers
> Zoran


Don't drink *too* much on Saturday...   :-)

Cheers!

Re: [naviserver-devel] Naviserver and OACS (compatibility)?

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

I added the comment because the argument order is confusing.  We could
change the order, but it not be compatible with AOLserver.  Do large
bodies of code such as OpenACS use filter args?  I think they do...


Something we could change is registered procs.  Currently, an extra
args is always passed to the registered proc (a blank string if you
don't specify anything else).  Dropping this would be cleaner.  This
is an incompatible change, but it's easy to write code that works on
both AOLserver and NaviServer using defaults:

    proc my_registered_proc {{context default}} { ... }
    ns_register_proc GET /* my_registered_proc
    ns_register_proc GET /* my_registered_proc my_context

What do you think?


On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> It still has this comment, so we can get rid of that comment and fix the
> order at the same time:-))
>
> /*
>   * This really should be: cmd why ?arg?, but why and arg
>   * are reversed for backwards compatibility.
>   */
>
>
> Stephen Deasey wrote:
> > Fixed in CVS a couple of days ago.  My fault, I missread the original
> > code and thought that like registered procs, if you didn't explicitly
> > pass an arg a blank string was passed.  Should work now.
> >
> >
> >
> >
> > On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> >
> >>It is in
> >>
> >>int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
> >>
> >>why arg is added after script args
> >>
> >>We can change it easily to always specify why first
> >>
> >>
> >>Zoran Vasiljevic wrote:
> >>
> >>>Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
> >>>
> >>>
> >>>>>> ns_register_filter trace GET * myfilter
> >>>>>>
> >>>>>>calls now "myfilter {} WHY"
> >>>
> >>>
> >>>But *why* is this so? IOW, what is this empty argument
> >>>passed to the myfilter? Is this something we overlooked
> >>>or is it something done on purpose, or what?
> >>>
> >>>I mean, maybe somebody has the answer out of the sleeve
> >>>and if not, I will have to dig into that...
> >>>
> >>>Cheers
> >>>Zoran
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> >>>files
> >>>for problems?  Stop!  Download the new AJAX search engine that makes
> >>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK=
!
> >>>http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> >>>_______________________________________________
> >>>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/
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> >>for problems?  Stop!  Download the new AJAX search engine that makes
> >>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> >>http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> >>_______________________________________________
> >>naviserver-devel mailing list
> >>nav...@li...
> >>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> > _______________________________________________
> > 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/
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] Naviserver and OACS (compatibility)?

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

It still has this comment, so we can get rid of that comment and fix the 
order at the same time:-))

/*
  * This really should be: cmd why ?arg?, but why and arg
  * are reversed for backwards compatibility.
  */


Stephen Deasey wrote:
> Fixed in CVS a couple of days ago.  My fault, I missread the original
> code and thought that like registered procs, if you didn't explicitly
> pass an arg a blank string was passed.  Should work now.
> 
> 
> 
> 
> On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> 
>>It is in
>>
>>int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
>>
>>why arg is added after script args
>>
>>We can change it easily to always specify why first
>>
>>
>>Zoran Vasiljevic wrote:
>>
>>>Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
>>>
>>>
>>>>>> ns_register_filter trace GET * myfilter
>>>>>>
>>>>>>calls now "myfilter {} WHY"
>>>
>>>
>>>But *why* is this so? IOW, what is this empty argument
>>>passed to the myfilter? Is this something we overlooked
>>>or is it something done on purpose, or what?
>>>
>>>I mean, maybe somebody has the answer out of the sleeve
>>>and if not, I will have to dig into that...
>>>
>>>Cheers
>>>Zoran
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>>files
>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&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/
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>for problems?  Stop!  Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>_______________________________________________
>>naviserver-devel mailing list
>>nav...@li...
>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&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] Naviserver and OACS (compatibility)?

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

Fixed in CVS a couple of days ago.  My fault, I missread the original
code and thought that like registered procs, if you didn't explicitly
pass an arg a blank string was passed.  Should work now.




On 12/29/05, Vlad Seryakov <vl...@cr...> wrote:
> It is in
>
> int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)
>
> why arg is added after script args
>
> We can change it easily to always specify why first
>
>
> Zoran Vasiljevic wrote:
> >
> > Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
> >
> >>>>  ns_register_filter trace GET * myfilter
> >>>>
> >>>> calls now "myfilter {} WHY"
> >
> >
> > But *why* is this so? IOW, what is this empty argument
> > passed to the myfilter? Is this something we overlooked
> > or is it something done on purpose, or what?
> >
> > I mean, maybe somebody has the answer out of the sleeve
> > and if not, I will have to dig into that...
> >
> > Cheers
> > Zoran
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > 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/
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] Naviserver and OACS (compatibility)?

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

It is in

int NsTclFilterProc(void *arg, Ns_Conn *conn, int why)

why arg is added after script args

We can change it easily to always specify why first


Zoran Vasiljevic wrote:
> 
> Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:
> 
>>>>  ns_register_filter trace GET * myfilter
>>>>
>>>> calls now "myfilter {} WHY"
> 
> 
> But *why* is this so? IOW, what is this empty argument
> passed to the myfilter? Is this something we overlooked
> or is it something done on purpose, or what?
> 
> I mean, maybe somebody has the answer out of the sleeve
> and if not, I will have to dig into that...
> 
> Cheers
> Zoran
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&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] Naviserver and OACS (compatibility)?

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

Am 29.12.2005 um 20:54 schrieb Vlad Seryakov:

>>>  ns_register_filter trace GET * myfilter
>>>
>>> calls now "myfilter {} WHY"

But *why* is this so? IOW, what is this empty argument
passed to the myfilter? Is this something we overlooked
or is it something done on purpose, or what?

I mean, maybe somebody has the answer out of the sleeve
and if not, I will have to dig into that...

Cheers
Zoran

Re: [naviserver-devel] Naviserver and OACS (compatibility)?

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

In all my code i never used args in the filters, i always define filter 
as proc filter { args} so for me it does not matter the order of the 
arguments. Logically, WHY should be the first arg.

Zoran Vasiljevic wrote:
> Hi!
> 
> I believe you guys are more familiar with this stuff
> as I am. Can you please comment?
> 
> Gustaf Neumann (XOTcl) is trying to get OACS to work
> with our code and has some remarks. I'm forwarding the
> relevant portion of an email sent to me today.
> 
> 
>> i made some changes to oacs such it works with naviserver. The biggest
>> problem was the changed argument passing conventions for filters. i am
>> not sure, that the agument passing conventions of naviserver are  the 
>> best
>> possible choice, since
>>
>>  ns_register_filter trace GET * myfilter
>>
>> calls now "myfilter {} WHY"
>> instead of "myfilter WHY" as it was before. It should not be
>> necessary to pass a nonexisting argument around. I would finde
>> it more logically to have this as
>>    "myfilter WHY"
>> or, when arguments are passed as
>>    "myfilter WHY arg1 arg2 ...."
>>
>> Since on has to alter the filter procs anyhow when moving from  
>> aolserver,
>> this would not have beed a bad choice. With xotcl, i use e.g.
>> an object handling the filter requests, such as
>> Object create filter
>> filter proc preauth ....
>> filter proc postauth ...
>> filter proc trace ....
>>
>> this worked nicely with the aolserver argument passing. now i have  to 
>> use
>> the strange looking method, that removes the empty first arg...
>>
>>  filter proc {} args {my eval $args}
>>
>> Did you have some discussions about this? Is it to late to change  this?
>>
>> In order to use oacs with naviserver, i had to introduce the following
>> not very beautifiul mapping rules to keep the changes minimal and
>> keep the server working for aolserver and naviserver.
>>
>> all the best
>> -gustaf
>>
>>
>> if {[ns_info name] eq "NaviServer"} {
>>  foreach filter {rp_filter rp_resources_filter  request_denied_filter} {
>>    rename $filter ${filter}_aolserver
>>    proc $filter {_ why} [list ${filter}_aolserver \$why]
>>  }
>>
>>  rename rp_invoke_filter rp_invoke_filter_conn
>>  proc   rp_invoke_filter { filter_info why }  { rp_invoke_filter_conn 
>> {} $filter_info $why }
>>  rename rp_invoke_proc   rp_invoke_proc_conn
>>  proc   rp_invoke_proc   { argv }            { rp_invoke_proc_conn  {} 
>> $argv }
>>
>>  rename rp_handler rp_handler_aolserver
>>  proc rp_handler {_} {rp_handler_aolserver}
>> }
>>
>>
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&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/

[naviserver-devel] Naviserver and OACS (compatibility)?

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

Hi!

I believe you guys are more familiar with this stuff
as I am. Can you please comment?

Gustaf Neumann (XOTcl) is trying to get OACS to work
with our code and has some remarks. I'm forwarding the
relevant portion of an email sent to me today.


> i made some changes to oacs such it works with naviserver. The biggest
> problem was the changed argument passing conventions for filters. i am
> not sure, that the agument passing conventions of naviserver are  
> the best
> possible choice, since
>
>  ns_register_filter trace GET * myfilter
>
> calls now "myfilter {} WHY"
> instead of "myfilter WHY" as it was before. It should not be
> necessary to pass a nonexisting argument around. I would finde
> it more logically to have this as
>    "myfilter WHY"
> or, when arguments are passed as
>    "myfilter WHY arg1 arg2 ...."
>
> Since on has to alter the filter procs anyhow when moving from  
> aolserver,
> this would not have beed a bad choice. With xotcl, i use e.g.
> an object handling the filter requests, such as
> Object create filter
> filter proc preauth ....
> filter proc postauth ...
> filter proc trace ....
>
> this worked nicely with the aolserver argument passing. now i have  
> to use
> the strange looking method, that removes the empty first arg...
>
>  filter proc {} args {my eval $args}
>
> Did you have some discussions about this? Is it to late to change  
> this?
>
> In order to use oacs with naviserver, i had to introduce the following
> not very beautifiul mapping rules to keep the changes minimal and
> keep the server working for aolserver and naviserver.
>
> all the best
> -gustaf
>
>
> if {[ns_info name] eq "NaviServer"} {
>  foreach filter {rp_filter rp_resources_filter  
> request_denied_filter} {
>    rename $filter ${filter}_aolserver
>    proc $filter {_ why} [list ${filter}_aolserver \$why]
>  }
>
>  rename rp_invoke_filter rp_invoke_filter_conn
>  proc   rp_invoke_filter { filter_info why }  
> { rp_invoke_filter_conn {} $filter_info $why }
>  rename rp_invoke_proc   rp_invoke_proc_conn
>  proc   rp_invoke_proc   { argv }            { rp_invoke_proc_conn  
> {} $argv }
>
>  rename rp_handler rp_handler_aolserver
>  proc rp_handler {_} {rp_handler_aolserver}
> }
>
>
>

[naviserver-devel] happy christmas

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

To all of you dear friends.
It was a very good year and it was a great
pleasure to work with you.

Cheers
Zoran

Re: [naviserver-devel] nacache

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

Am 23.12.2005 um 20:03 schrieb Stephen Deasey:

> Yes, good points.  I've uploaded a new patch which merges everything
> into the core with minimal changes to existing C code.  Let me know
> how this looks.

Great!

>
> Regarding API compatibility for Tcl code, I thought a wrapper ns_cache
> command could be added to the tcl/cache.tcl file.  What do you think?

You mean "ns_cache eval" -> "ns_cache_eval" stuff? Yes, just place
them there. There are not too many of them anyways.
When I look thru our code, we just use ns_cache (create, eval, flush)
so I will go and rename them to ns_cache_create etc.

And, commit that code.
And, happy christmas to you all!

Thanks,
Zoran

Re: [naviserver-devel] nacache

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

Looks like a good patch, can you just commit it.

Happy Holidays!

Stephen Deasey wrote:
> On 12/11/05, Vlad Seryakov <vl...@cr...> wrote:
> 
>>Yes, "just-create" policy is fine, clearing the cache but keeping it
>>empty is not bad. Reduceing locks with nscache is actually a big deal
>>but at this point compatibility with old API is a higher priority, too
>>much production code.
>>
>>Let's see what Stephen will say :-))
>>
>>Zoran Vasiljevic wrote:
>>
>>>On 11.12.2005, at 18:39, Vlad Seryakov wrote:
>>>
>>>
>>>>Can we just put existing module into the core? It's been working  good
>>>>in the past.
>>>
>>>
>>>I have nothing against. We use this module for years and it just  works
>>>fine.
>>>I also like Stephens less-locking approach but only one thing bothers me
>>>there: inability to create new caches during runtime.
>>>I'd also accept "just creating and not tearing down" caches as this  would
>>>suffice us.
> 
> 
> Yes, good points.  I've uploaded a new patch which merges everything
> into the core with minimal changes to existing C code.  Let me know
> how this looks.
> 
> Regarding API compatibility for Tcl code, I thought a wrapper ns_cache
> command could be added to the tcl/cache.tcl file.  What do you think?
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&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] nacache

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

On 12/11/05, Vlad Seryakov <vl...@cr...> wrote:
> Yes, "just-create" policy is fine, clearing the cache but keeping it
> empty is not bad. Reduceing locks with nscache is actually a big deal
> but at this point compatibility with old API is a higher priority, too
> much production code.
>
> Let's see what Stephen will say :-))
>
> Zoran Vasiljevic wrote:
> >
> > On 11.12.2005, at 18:39, Vlad Seryakov wrote:
> >
> >>
> >> Can we just put existing module into the core? It's been working  good
> >> in the past.
> >
> >
> > I have nothing against. We use this module for years and it just  works
> > fine.
> > I also like Stephens less-locking approach but only one thing bothers m=
e
> > there: inability to create new caches during runtime.
> > I'd also accept "just creating and not tearing down" caches as this  wo=
uld
> > suffice us.

Yes, good points.  I've uploaded a new patch which merges everything
into the core with minimal changes to existing C code.  Let me know
how this looks.

Regarding API compatibility for Tcl code, I thought a wrapper ns_cache
command could be added to the tcl/cache.tcl file.  What do you think?

Re: [naviserver-devel] nacache

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

Yes, "just-create" policy is fine, clearing the cache but keeping it 
empty is not bad. Reduceing locks with nscache is actually a big deal 
but at this point compatibility with old API is a higher priority, too 
much production code.

Let's see what Stephen will say :-))

Zoran Vasiljevic wrote:
> 
> On 11.12.2005, at 18:39, Vlad Seryakov wrote:
> 
>>
>> Can we just put existing module into the core? It's been working  good 
>> in the past.
> 
> 
> I have nothing against. We use this module for years and it just  works 
> fine.
> I also like Stephens less-locking approach but only one thing bothers me
> there: inability to create new caches during runtime.
> I'd also accept "just creating and not tearing down" caches as this  would
> suffice us.
> 
> Cheers
> Zoran
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&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] nacache

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

On 11.12.2005, at 18:39, Vlad Seryakov wrote:

>
> Can we just put existing module into the core? It's been working  
> good in the past.

I have nothing against. We use this module for years and it just  
works fine.
I also like Stephens less-locking approach but only one thing bothers me
there: inability to create new caches during runtime.
I'd also accept "just creating and not tearing down" caches as this  
would
suffice us.

Cheers
Zoran

[naviserver-devel] nacache

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

Helo Guys,

Can we close nscache incorporating into the core?

I will be soon producing some product involving naviserver which uses 
nscache and having it in the core would simplify life a little bit.

But if it will not be backward compatible, this will introduce more 
problems because ther are a lot of software using ns_cache API.

Can we just put existing module into the core? It's been working good in 
the past.

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

Re: [naviserver-devel] Excessive locking in urlspace?

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

You can continue to call ns_unregister_proc.

The comment was for Ns_UrlSpecificDestroy:

    Side effects:
        Will remove data from urlspace; don't call this after server
        startup.

I think this is wrong, so I removed the comment.  If this isn't the
case, I guess we've had a problem all along...

Re compatibility, there are a couple of notes for C module writers in
the patch description.



On 12/9/05, Vlad Seryakov <vl...@cr...> wrote:
> So, that means ns_register_proc i can call, but not ns_unregister_proc?
>
> I have nothing against the patch if no incompabilities will be raised.
>
> Stephen Deasey wrote:
> > Yes, you must still be able to register procs at runtime. (There is a
> > comment in urlspace.c saying you musn't call destroy at runtime...?)
> >
> > I guess my real question was is this the right way to do it?  I
> > originally thought that maybe the urlspace code should hadle all the
> > locking.  I think the idea below is simpler and more flexible.  So
> > here's a patch:
> >
> > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1377113&gr=
oup_id=3D130646&atid=3D719009
> >
> >
> > The conn pool code is now lock free!
> >
> >
> > On 12/7/05, Vlad Seryakov <vl...@cr...> wrote:
> >
> >>I think ns_register_proc/ns_register_filter uses Trie and canbe called
> >>at any time, that's why it still needs locking.
> >>
> >>Double locking should be avoided but i would keep the ability to call
> >>ns_registerXXX procs at any time.
> >>
> >>Stephen Deasey wrote:
> >>
> >>>Ns_ConnRunRequest in op.c does something like:
> >>>
> >>>Ns_MutexLock(&ulock);
> >>>reqPtr =3D Ns_UrlSpecificGet(server, method, url, id);
> >>>...
> >>>Ns_MutexUnlock(&ulock);
> >>>
> >>>
> >>>Ns_UrlSpecificGet in urlspace.c does something like:
> >>>
> >>>MkSeq(&seq, server, method, url);
> >>>Ns_MutexLock(&lock);
> >>>data =3D JunctionFind(&urlspace, seq, id, 0);
> >>>Ns_MutexUnlock(&lock);
> >>>
> >>>
> >>>i.e. there's double locking going on.  The second lock, in the
> >>>urlspace code, is under contention by all callers of urlspace
> >>>(requests, url2file, etc.), and many of these are very common
> >>>operations.
> >>>
> >>>
> >>>Users of urlspace need to call Ns_UrlSpecificAlloc() in their
> >>>initialisation code to get a magic ID.  This ID partitions the data of
> >>>each subsystem.  But the ID is stored within the 'Trie' and so needs
> >>>to be protected by the global lock.
> >>>
> >>>What if instead the ID was used as in Thread Local Storage?  There's
> >>>an array of slots, where each slot contains a separate Trie, and the
> >>>ID is an index into this array.  Because ID's are allocated at start
> >>>up and aren't destroyed there need be no locking at run time to locate
> >>>the appropriate Trie for the caller.
> >>>
> >>>The urlspace locking can now be removed because the callers locking
> >>>perfectly protects the Trie from concurrent access.  It would also
> >>>allow the caller to run lock-free in the case where all urlspace
> >>>entries are created at start up and only read at run time.
> >>>
> >>>
> >>>Does this make sense?

Re: [naviserver-devel] Excessive locking in urlspace?

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

So, that means ns_register_proc i can call, but not ns_unregister_proc?

I have nothing against the patch if no incompabilities will be raised.

Stephen Deasey wrote:
> Yes, you must still be able to register procs at runtime. (There is a
> comment in urlspace.c saying you musn't call destroy at runtime...?)
> 
> I guess my real question was is this the right way to do it?  I
> originally thought that maybe the urlspace code should hadle all the
> locking.  I think the idea below is simpler and more flexible.  So
> here's a patch:
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=1377113&group_id=130646&atid=719009
> 
> 
> The conn pool code is now lock free!
> 
> 
> On 12/7/05, Vlad Seryakov <vl...@cr...> wrote:
> 
>>I think ns_register_proc/ns_register_filter uses Trie and canbe called
>>at any time, that's why it still needs locking.
>>
>>Double locking should be avoided but i would keep the ability to call
>>ns_registerXXX procs at any time.
>>
>>Stephen Deasey wrote:
>>
>>>Ns_ConnRunRequest in op.c does something like:
>>>
>>>Ns_MutexLock(&ulock);
>>>reqPtr = Ns_UrlSpecificGet(server, method, url, id);
>>>...
>>>Ns_MutexUnlock(&ulock);
>>>
>>>
>>>Ns_UrlSpecificGet in urlspace.c does something like:
>>>
>>>MkSeq(&seq, server, method, url);
>>>Ns_MutexLock(&lock);
>>>data = JunctionFind(&urlspace, seq, id, 0);
>>>Ns_MutexUnlock(&lock);
>>>
>>>
>>>i.e. there's double locking going on.  The second lock, in the
>>>urlspace code, is under contention by all callers of urlspace
>>>(requests, url2file, etc.), and many of these are very common
>>>operations.
>>>
>>>
>>>Users of urlspace need to call Ns_UrlSpecificAlloc() in their
>>>initialisation code to get a magic ID.  This ID partitions the data of
>>>each subsystem.  But the ID is stored within the 'Trie' and so needs
>>>to be protected by the global lock.
>>>
>>>What if instead the ID was used as in Thread Local Storage?  There's
>>>an array of slots, where each slot contains a separate Trie, and the
>>>ID is an index into this array.  Because ID's are allocated at start
>>>up and aren't destroyed there need be no locking at run time to locate
>>>the appropriate Trie for the caller.
>>>
>>>The urlspace locking can now be removed because the callers locking
>>>perfectly protects the Trie from concurrent access.  It would also
>>>allow the caller to run lock-free in the case where all urlspace
>>>entries are created at start up and only read at run time.
>>>
>>>
>>>Does this make sense?
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&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] Excessive locking in urlspace?

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

Yes, you must still be able to register procs at runtime. (There is a
comment in urlspace.c saying you musn't call destroy at runtime...?)

I guess my real question was is this the right way to do it?  I
originally thought that maybe the urlspace code should hadle all the
locking.  I think the idea below is simpler and more flexible.  So
here's a patch:

http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1377113&group_=
id=3D130646&atid=3D719009


The conn pool code is now lock free!


On 12/7/05, Vlad Seryakov <vl...@cr...> wrote:
> I think ns_register_proc/ns_register_filter uses Trie and canbe called
> at any time, that's why it still needs locking.
>
> Double locking should be avoided but i would keep the ability to call
> ns_registerXXX procs at any time.
>
> Stephen Deasey wrote:
> > Ns_ConnRunRequest in op.c does something like:
> >
> > Ns_MutexLock(&ulock);
> > reqPtr =3D Ns_UrlSpecificGet(server, method, url, id);
> > ...
> > Ns_MutexUnlock(&ulock);
> >
> >
> > Ns_UrlSpecificGet in urlspace.c does something like:
> >
> > MkSeq(&seq, server, method, url);
> > Ns_MutexLock(&lock);
> > data =3D JunctionFind(&urlspace, seq, id, 0);
> > Ns_MutexUnlock(&lock);
> >
> >
> > i.e. there's double locking going on.  The second lock, in the
> > urlspace code, is under contention by all callers of urlspace
> > (requests, url2file, etc.), and many of these are very common
> > operations.
> >
> >
> > Users of urlspace need to call Ns_UrlSpecificAlloc() in their
> > initialisation code to get a magic ID.  This ID partitions the data of
> > each subsystem.  But the ID is stored within the 'Trie' and so needs
> > to be protected by the global lock.
> >
> > What if instead the ID was used as in Thread Local Storage?  There's
> > an array of slots, where each slot contains a separate Trie, and the
> > ID is an index into this array.  Because ID's are allocated at start
> > up and aren't destroyed there need be no locking at run time to locate
> > the appropriate Trie for the caller.
> >
> > The urlspace locking can now be removed because the callers locking
> > perfectly protects the Trie from concurrent access.  It would also
> > allow the caller to run lock-free in the case where all urlspace
> > entries are created at start up and only read at run time.
> >
> >
> > Does this make sense?

Re: [naviserver-devel] Excessive locking in urlspace?

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

I think ns_register_proc/ns_register_filter uses Trie and canbe called 
at any time, that's why it still needs locking.

Double locking should be avoided but i would keep the ability to call 
ns_registerXXX procs at any time.

Stephen Deasey wrote:
> Ns_ConnRunRequest in op.c does something like:
> 
> Ns_MutexLock(&ulock);
> reqPtr = Ns_UrlSpecificGet(server, method, url, id);
> ...
> Ns_MutexUnlock(&ulock);
> 
> 
> Ns_UrlSpecificGet in urlspace.c does something like:
> 
> MkSeq(&seq, server, method, url);
> Ns_MutexLock(&lock);
> data = JunctionFind(&urlspace, seq, id, 0);
> Ns_MutexUnlock(&lock);
> 
> 
> i.e. there's double locking going on.  The second lock, in the
> urlspace code, is under contention by all callers of urlspace
> (requests, url2file, etc.), and many of these are very common
> operations.
> 
> 
> Users of urlspace need to call Ns_UrlSpecificAlloc() in their
> initialisation code to get a magic ID.  This ID partitions the data of
> each subsystem.  But the ID is stored within the 'Trie' and so needs
> to be protected by the global lock.
> 
> What if instead the ID was used as in Thread Local Storage?  There's
> an array of slots, where each slot contains a separate Trie, and the
> ID is an index into this array.  Because ID's are allocated at start
> up and aren't destroyed there need be no locking at run time to locate
> the appropriate Trie for the caller.
> 
> The urlspace locking can now be removed because the callers locking
> perfectly protects the Trie from concurrent access.  It would also
> allow the caller to run lock-free in the case where all urlspace
> entries are created at start up and only read at run time.
> 
> 
> Does this make sense?
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&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/

[naviserver-devel] Excessive locking in urlspace?

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

Ns_ConnRunRequest in op.c does something like:

Ns_MutexLock(&ulock);
reqPtr =3D Ns_UrlSpecificGet(server, method, url, id);
...
Ns_MutexUnlock(&ulock);


Ns_UrlSpecificGet in urlspace.c does something like:

MkSeq(&seq, server, method, url);
Ns_MutexLock(&lock);
data =3D JunctionFind(&urlspace, seq, id, 0);
Ns_MutexUnlock(&lock);


i.e. there's double locking going on.  The second lock, in the
urlspace code, is under contention by all callers of urlspace
(requests, url2file, etc.), and many of these are very common
operations.


Users of urlspace need to call Ns_UrlSpecificAlloc() in their
initialisation code to get a magic ID.  This ID partitions the data of
each subsystem.  But the ID is stored within the 'Trie' and so needs
to be protected by the global lock.

What if instead the ID was used as in Thread Local Storage?  There's
an array of slots, where each slot contains a separate Trie, and the
ID is an index into this array.  Because ID's are allocated at start
up and aren't destroyed there need be no locking at run time to locate
the appropriate Trie for the caller.

The urlspace locking can now be removed because the callers locking
perfectly protects the Trie from concurrent access.  It would also
allow the caller to run lock-free in the case where all urlspace
entries are created at start up and only read at run time.


Does this make sense?