Re: [naviserver-devel] ns_cond wait (Was: hosting java-script server-side?)

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

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.