[ naviserver-Feature Requests-1161597 ] Extend ns_info with info about traces/filters/procs

[SourceForge.net <no...@so...>]

Feature Requests item #1161597, was opened at 2005-03-11 12:30
Message generated for change (Comment added) made by sdeasey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1161597&group_id=130646

Category: C-API
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vlad Seryakov (seryakov)
Assigned to: Vlad Seryakov (seryakov)
Summary: Extend ns_info with info about traces/filters/procs

Initial Comment:
Attached is patch that extends ns_info with 3 commands:

ns_info traces
ns_info filters
ns_info requestprocs

They work the same way as ns_info callbacks, no
functionality changed or added, just information commands

----------------------------------------------------------------------

>Comment By: Stephen Deasey (sdeasey)
Date: 2005-03-27 07:40

Message:
Logged In: YES 
user_id=87254


Hmm, I think the arg proc stuff is just for the callback and
arg registered at some point in the data structure.  The
function which navigates the data structure obviously has to
know the details, so it doesn't need a callback.

So, the only functions which need this treatment would be
NsFastGet and NsAdpProc.  The arg passed to these is really
dull, just a pointer to the server which you'll already know
from walking the url trie, so really all that needs added to
proc.c is something like:

{(void *) NsAdpProc, "ns:adp", NULL},
{(void *) NsFastGet, "ns:fastget", NULL},

i.e. name the proc, but don't bother providing a callback to
describe the arg.



----------------------------------------------------------------------

Comment By: Vlad Seryakov (seryakov)
Date: 2005-03-17 07:22

Message:
Logged In: YES 
user_id=184124

Yes, this is what i did with UrlSpecific walk function, it
will call Ns_ArpProc for every node which will append
what-ever info to DString. We can live with that for the
beginning, anyway, that info will be used in Tcl and should
be converted into strings. 
So, i guess i can add info proc for UrlSpecific trie?

----------------------------------------------------------------------

Comment By: Stephen Deasey (sdeasey)
Date: 2005-03-17 04:06

Message:
Logged In: YES 
user_id=87254


To get info on the binary callbacks we're just going to have
to register proc info for all the default filters, request
procs etc.  If we cover everything there should be a
reasonable number of examples for module writers to follow.



----------------------------------------------------------------------

Comment By: Vlad Seryakov (seryakov)
Date: 2005-03-12 18:47

Message:
Logged In: YES 
user_id=184124

Also, somein docs would be usefull to put info how to get
info about some binary callbacks:

Welcome to ossweb running at /usr/local/ns/bin/nsd (pid 5524)
ossweb:nscp 1> ns_info traces
p:0xb7187be0 a:0x80817d8

# gdb
(gdb) attach 12345

(gdb) info symbol 0xb7187be0
LogTrace in section .text





----------------------------------------------------------------------

Comment By: Vlad Seryakov (seryakov)
Date: 2005-03-12 18:44

Message:
Logged In: YES 
user_id=184124

I started with minimal changes, #defines and &syntax can be
chnages of course. now that you started TclCallbacks, this
thing depends when you commit your changes, it requires
Ns_ArgProc and ns_info stuff.
Once we have unified API for callbask i will change it to be
server-specific as well, it took a while to figure out how
it works :-))

----------------------------------------------------------------------

Comment By: Stephen Deasey (sdeasey)
Date: 2005-03-12 18:37

Message:
Logged In: YES 
user_id=87254


This is a nice addition.  

ns_info filters/traces is server specific, but ns_info
requestprocs returns info for all servers.  Can you make
this per-server also, to be consistent?

The URL walking procs look a little tricky, I tnink they
would benefit from having their own more detailed comments.

The comment currently says it calls a function for each
node, and the effect depends on the function.  But the
function signature is Ns_ArgProc so there's really only one
thing it can do.

Why does it fix the stack size at 512?  Can these magic
numbers be #define'd.

Using a while loop rather than an empty for loop would be a
little easier to read.

There's a lot of this kind of thing:
    (&(triePtr->branches))->n
Could this be simplified to:
    triePtr->branches.n ?


Otherwise, looks pretty good.  I like it.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1161597&group_id=130646