On 04.10.2006, at 21:33, Stephen Deasey wrote:
The control port is not typical. It's probably evaluating each line
with the "no-compile" flag. Neither is the runtest shell, which is
what I was using.
NO! It is FAR more complex than you think...
I added this:
proc lu count {
ns_log notice LOCK.$count
ns_mutex lock m
ns_mutex unlock m
ns_log notice UNLOCK.$count
}
into tcl/util.c and restarted the server.
Then I went to ctrl port and did:
server1:nscp 1> lu 1
server1:nscp 2> lu 2
server1:nscp 3> lu 3
and got
[04/Oct/2006:21:37:35][5931.41968128][-nscp:2-] Notice: LOCK.1
[04/Oct/2006:21:37:35][5931.41968128][-nscp:2-] Error: MISS THE OBJ
CACHE : 0x2f3858
[04/Oct/2006:21:37:35][5931.41968128][-nscp:2-] Notice: UNLOCK.1
[04/Oct/2006:21:37:38][5931.41968128][-nscp:2-] Notice: LOCK.2
[04/Oct/2006:21:37:38][5931.41968128][-nscp:2-] Notice: UNLOCK.2
[04/Oct/2006:21:37:38][5931.41968128][-nscp:2-] Notice: LOCK.3
[04/Oct/2006:21:37:38][5931.41968128][-nscp:2-] Notice: UNLOCK.3
Now, you would naively (as myself) think all is green.
Its not.
Because when I do following (on the ncp line)
server1:nscp 11> proc lu count {ns_log notice LOCK.$count; ns_mutex
lock m; ns_mutex unlock m; ns_log notice UNLOCK.$count}
i.e. redefine the proc "lu" then I get the cache misses again.
As you might expect because the ncp is "probably" not compiling
the proc. Allright, but when I logout the ncp and log in again
the completely new thread is created and the "lu" procedure
is again created from the blueprint. AND... if I now repeat
my test i get:
[04/Oct/2006:21:39:08][5931.41967104][-nscp:3-] Notice: LOCK.1
[04/Oct/2006:21:39:08][5931.41967104][-nscp:3-] Error: MISS THE OBJ
CACHE : 0x2f34b0
[04/Oct/2006:21:39:08][5931.41967104][-nscp:3-] Error: MISS THE OBJ
CACHE : 0x2f34b0
[04/Oct/2006:21:39:08][5931.41967104][-nscp:3-] Notice: UNLOCK.1
[04/Oct/2006:21:39:10][5931.41967104][-nscp:3-] Notice: LOCK.2
[04/Oct/2006:21:39:10][5931.41967104][-nscp:3-] Error: MISS THE OBJ
CACHE : 0x2f34b0
[04/Oct/2006:21:39:10][5931.41967104][-nscp:3-] Error: MISS THE OBJ
CACHE : 0x2f34b0
[04/Oct/2006:21:39:10][5931.41967104][-nscp:3-] Notice: UNLOCK.2
[04/Oct/2006:21:39:12][5931.41967104][-nscp:3-] Notice: LOCK.3
[04/Oct/2006:21:39:12][5931.41967104][-nscp:3-] Error: MISS THE OBJ
CACHE : 0x2f34b0
[04/Oct/2006:21:39:12][5931.41967104][-nscp:3-] Error: MISS THE OBJ
CACHE : 0x2f34b0
[04/Oct/2006:21:39:12][5931.41967104][-nscp:3-] Notice: UNLOCK.3
As you see... it is much more complicated and I can't really
explain w/o deeply looking into it. There is something
happening there which we still do not understand.
But I don't know if that makes this technique not useful...
It is useful. But it has side-effects we will yet
have to understand.
Right. So if handle management was implicit you wouldn't have to
bother shuffling them between interps via nsv arrays. Which would be a
good thing.
Of course. I never sad something different.
The global lock is just my laziness. Although if the handle is cached
it doesn't matter because the lock is only taken once, the first time.
And it has to be cached or else there's no point doing this...
It is cached *sometimes* and we do not know why not, when not.
At least I don't as I can reproduce the above behaviour easly.
