Hi,
I hope someone with a better understanding of the inner workings of nsv
can answer this for me:
I would like to store application settings in the database, then on
startup, load these into memory and be able to update those on the fly
afterwards. nsv sets come into mind to do that. Would
docs on their security design:
http://openacs.org/doc/openacs-4/security-design.html
Tim
-Original Message-
From: AOLserver Discussion [mailto:[EMAIL PROTECTED]]On Behalf
Of Bas Scheffers
Sent: Tuesday, February 18, 2003 9:59 AM
To: [EMAIL PROTECTED]
Subject: [AOLSERVER] nsv
On Saturday 09 November 2002 19:43, you wrote:
Since the TCL core already has all this stuff in it about binding TCL
vars to C vars, it seems plausible to use it for ns_shares and get
7.6-like performance without needing traces.
Ehm... the Tcl bindings *use* traces internally, i.e. on
In a message dated 11/8/2002 10:50:19 AM Eastern Standard Time, [EMAIL PROTECTED] writes:
On Fri, Nov 08, 2002 at 07:36:33AM -0800, Jim Wilcoxson wrote:
Creating a TCL-accessible array in a C module is trival. Just pass
Ah, thanks! Sometimes having one simple example in front of you is so
much
On Fri, Nov 08, 2002 at 05:34:43PM -0500, Nathan Folkman wrote:
In a message dated 11/8/2002 10:50:19 AM Eastern Standard Time,
[EMAIL PROTECTED] writes:
Well, AOLserver really SHOULD ship with a C API to nsv, but since it
doesn't, I created my own partial one. It was pretty easy. But
In a message dated 11/8/2002 5:42:25 PM Eastern Standard Time, [EMAIL PROTECTED] writes:
I'm not sure, but I think Zoran already DID make his stuff backwards
compatabile with the nsv_* API. I haven't tried his (way cool, btw!)
Tcl Thead Extension yet, but last I checked its tls code was organized
On Friday 08 November 2002 23:34, you wrote:
Perhaps nsv should be replaced with the svar work Zoran had worked on? You
could provide backwards compatibility wrappers of course. What do you think
Zoran?
The code in current threading extension, implementing the thread shared
variables (aka
Could you not call NsTclVSetCmd() yourself? Look in
nsd/tclvar.c ...
-- Dossy
On 2002.05.03, Andrew Piskorski [EMAIL PROTECTED] wrote:
Folks, has anyone implemented a C NSV API, or does anyone plan to?
Clearly the right thing to do would be to move the functinality in
You should use the following:
static int
BB_NsvSet(const char *nsvString,
const char *keyString, const char *valueString)
{
Tcl_Obj *o[4];
o[0]=Tcl_NewStringObj(nsv_set,7);
o[1]=Tcl_NewStringObj(nsvString,-1);
o[2]=Tcl_NewStringObj(keyString,-1);
On Sat, May 04, 2002 at 01:31:42AM -0400, Dossy wrote:
Could you not call NsTclVSetCmd() yourself? Look in
nsd/tclvar.c ...
Hm. NsTclVSetCmd() does stuff to or with the Tcl interpretor, and I
don't HAVE any convenient local interp pointer in my C function to
pass is. Should I be passing the
On Sat, May 04, 2002 at 11:06:09AM -0400, Dossy wrote:
On 2002.05.04, Andrew Piskorski [EMAIL PROTECTED] wrote:
On Sat, May 04, 2002 at 01:31:42AM -0400, Dossy wrote:
If you're not passing the interp to Ns_TclEval to tell it in which
interpreter to perform the TclEval ... then don't you
On 2002.05.04, Andrew Piskorski [EMAIL PROTECTED] wrote:
I haven't studied the tclvar.c much, but why would nsv locks have
anything to do with threads at all? The nsv data structures are
server-wide, after all, so I don't THINK there's anything per-thread
or per-interp about them at all.
Dave Siktberg wrote:
I am using nsv arrays to hold session data across multiple page accesses,
etc (snipped for brevity..)
Is there any way to monitor the amount of space consumed by nsv arrays at
any point in time? What should I do to monitor the performance impact of my
nsv use
I am using nsv arrays to hold session data across multiple page accesses,
and to hold some relatively static widely-shared database data to avoid
unnecessary database reads. Probably at any point in time there will be
several hundred plus nsv arrays with a few K bytes in each, but I haven't
In the interests of simplicity, if your site is really going to get light
to modest traffic,, you may find that the system performs adequately
without using the nsv arrays for this data. I'd say that unless you're
looking at more than 100 page reads per minute, you might be just fine,
especially
can someone point me to the new location of the nsv docs?
thanks,
scott laplante
nsv docs are at http://www.aolserver.com/docs/devel/tcl/nsv-commands.adp
-Original Message-
From: AOLserver Discussion [mailto:[EMAIL PROTECTED]]On Behalf
Of Scott Laplante
Sent: Thursday, November 15, 2001 12:32 PM
To: [EMAIL PROTECTED]
Subject: [AOLSERVER] nsv docs
can someone point
All,
I've got an issue with lock contention using nsvs.
Our site has a huge hash table of categories that is loaded once when the
server starts, and is modified rarely. It is used frequently throughout the
site. Currently we're keeping it in an nsv.
The problem is, under heavy load, we get
If there is any possibility, try breaking up you array into several
arrays. Then you can use more than one nsv bucket. Or how do tcl arrays
work? If they use a hashtable as well, then you can use a global array,
can't you?
global copy_array
array set copy_array [nsv_array get main_array]
--Tom
Sean Owen wrote:
All,
I've got an issue with lock contention using nsvs.
Our site has a huge hash table of categories that is loaded once when the
server starts, and is modified rarely. It is used frequently throughout the
site. Currently we're keeping it in an nsv.
The problem is, under
+-- On Sep 10, Sean Owen said:
The problem is, under heavy load, we get into serious lock contention
problems reading from it.
Are you speculating or have you looked at the mutex statistics?
99.99% of the time we are just reading, so
ideally I'd like to use something akin to a
Okay, so one time out of ten thousand will be a write to the structure.
Is it important that:
A) if at time t, a thread determines that slot n should be modified,
must all reads from t on find the new, modified value, or would it
be okay for other threads to use the old value for some
+-- On Sep 10, Jerry Asher said:
Modifying the table becomes lengthy, you need to verify on your platform
that you can swap a pointer in an atomic operation, readers can get old
values for some period of time, but readers never have to lock the table.
Consider this:
reader is
At 07:28 PM 9/10/01, you wrote:
+-- On Sep 10, Jerry Asher said:
Modifying the table becomes lengthy, you need to verify on your platform
that you can swap a pointer in an atomic operation, readers can get old
values for some period of time, but readers never have to lock the table.
To answer the various responses I've received:
I have verified the lock contention problem by viewing mutex statistics. The
offending nsv bucket got 100 times more locks than any other, and under
heavy load was busy up to 48% of the time. Not good.
I also verified that the hashtable in question
This is true, but is atomicity really required? If you don't mind the memory
being taken up for a few extra cycles, it seems to me that if you point the
API at the new version of the hash table, you can poll the reference count
for the old version once a second until it is zero, and then safely
+-- On Sep 10, Sean Owen said:
This is true, but is atomicity really required? If you don't mind the memory
being taken up for a few extra cycles, it seems to me that if you point the
API at the new version of the hash table, you can poll the reference count
for the old version once a
hi!
My question is about nsv interface
is there a way to get for example first key and value (that is not by
key, but position)
TIA
Remigiusz
--
---/\--
Remigiusz Sokolowski e-mail: [EMAIL PROTECTED]
No. NSV uses hashes so there really is no concept of a first key/value
pair.
/s.
hi!
My question is about nsv interface
is there a way to get for example first key and value (that is not by
key, but position)
TIA
Remigiusz
--
29 matches
Mail list logo
