naviserver-devel — Developer discussion

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

Am 14.07.2006 um 16:04 schrieb Vlad Seryakov:

> In the nstk module i have generic caching of compiled pages and  
> file.tcl
> can be modified to perform per-thread .tcl caching of bytecode as  
> well.

Yes, this is a trivial, poor-man's cache which is simple and works.
Cheers,
Zoran

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

In the nstk module i have generic caching of compiled pages and file.tcl 
can be modified to perform per-thread .tcl caching of bytecode as well.

proc ns_sourcefile { path } {

     set proc0 [info procs filecache_$path]
     set cookie0 $stat(mtime):$stat(ctime):$stat(ino):$stat(dev)
     # Verify file modification time
     if { $proc0 == "" || [$proc0 1] != $cookie0 } {
       set code [ns_fileread $path]
       proc filecache_$path {{getcookie 0}} "
          if { \$getcookie } { return $cookie0 }
          uplevel #$level { $code }
       "
     }
     # Run the proc
     filecache_$path
}


Zoran Vasiljevic wrote:
> Am 13.07.2006 um 23:40 schrieb Stephen Deasey:
> 
>> I was suggesting that maybe there should be a away around this as in
>> some cases, like ours, we specifically make sure that all interps are
>> identical: we create one master interp at start up and then clone it
>> for each new thread.  No one seemed excited by this though...
> 
> You can't do that, as when you compile:
> 
>    set a 1
> 
> in intrep A and interp B the "1" will result in different literal
> object so bytecode rep must be recompiled anyways. Even if you
> have one thread and several interps, each time the compiled
> bytecode object gets evaluated in the different interp, it gets
> recompiled.
> 
> Therefore I would suggest people who need last microsecond of
> performance to put most of the frequently used code in procedures.
> 
> Cheers
> Zoran
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> 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] SF CVS broken

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

Hi!

Aparently, some accounts cannot login to CVS as
they get their password rejected. Same for me as of
today. I do not know how long it will take now...

Cheers
Zoran

Re: [naviserver-devel] running callbacks

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

Am 13.07.2006 um 22:16 schrieb Stephen Deasey:

>
> Why can't you initialise resources when you register the callback?  I
> don't think I understand the problem here...

Well, my first idea was to get a kind of "self-initializing" and
"self-cleaning" procedures. Most importantly the "self-cleaning"
as "self-initializing" is pretty easy to make with kind-of
"static" variables.

So I *can* check if the callback is called for the first time
but I *do not* know when it is called for the last time!
Knowing when I'm called for the first time allows me to build
the internal cache, and knowing when I'm called the last time
allows me to cleanup. This way the initialization and cleanup
are inherent for the callback procedure and nothing else is
needed from the outside to make it happen.

But...

After thinking more and more, I see that we can't simply
generalize that to be backward compatible. And if we can't
do that, then we'd had pretty inelegant solution. Therefore
I will step back and do as you suggested: before I register
the callback I will manually initialize it, and after I
unregister I will manually invoke the cleanup.

I just though this can be somehow simplified but must admit
that this is not simple, given the code we already have.

So, consider this idea trashed. Sorry for the noise...

Cheers
Zoran

Re: [naviserver-devel] running callbacks

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

Am 13.07.2006 um 22:16 schrieb Stephen Deasey:

> Ns_TclCallbackArgProc is only for reporting purposes, so it doesn't
> much matter. There should be lots of tests for this in the test suite

Well, I see... for reporting this really does not matter.
The output of this command can't be used for anything else
so I will leave it as-is.

I will still have to think about adding more "notion" about the
operation of the callback, i.e. being registred, being unregistered
or being executed. This way it can be retro-fitted in the existing
callback w/o changing the API as Vlad suggested.

Well... thats next on my list...

Cheers
zoran

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

Am 13.07.2006 um 23:40 schrieb Stephen Deasey:

>
> I was suggesting that maybe there should be a away around this as in
> some cases, like ours, we specifically make sure that all interps are
> identical: we create one master interp at start up and then clone it
> for each new thread.  No one seemed excited by this though...

You can't do that, as when you compile:

   set a 1

in intrep A and interp B the "1" will result in different literal
object so bytecode rep must be recompiled anyways. Even if you
have one thread and several interps, each time the compiled
bytecode object gets evaluated in the different interp, it gets
recompiled.

Therefore I would suggest people who need last microsecond of
performance to put most of the frequently used code in procedures.

Cheers
Zoran

Re: [naviserver-devel] Bug in upload stats

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

> 
> Hmm, this code loops through all drivers looking for the matching URL.
>  But drivers can be mapped to different virtual servers, and some
> drivers can be shared among virtual servers, for name-based virtual
> hosting.

Yes, that's right. It should be virtual-server aware if it's worth 
anything at all.

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

Re: [naviserver-devel] Bug in upload stats

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

On 7/13/06, Vlad Seryakov <vl...@cr...> wrote:
> My bad :-(( Can you fix it, i cannot for some reason login into CVS over ssh
>

No problem.  I've left the tests for you -- I know that's your
favourite part...  :-)

Hmm, this code loops through all drivers looking for the matching URL.
 But drivers can be mapped to different virtual servers, and some
drivers can be shared among virtual servers, for name-based virtual
hosting.

Won't the URLs from different servers clash?

Re: [naviserver-devel] Encoding

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

On 7/13/06, Bernd Eidenschink <eid...@we...> wrote:
>
> Hi Vlad,
>
> > Or you can try to replace ReturnCharData in return.c and see if this
> > works (i did not test it):
>
> yes, it seems to work:
>
>   HTTP/1.1 200 OK
>   MIME-Version: 1.0
>   Accept-Ranges: bytes
>   Date: Thu, 13 Jul 2006 06:45:55 GMT
>   Server: NaviServer/4.99.2
>   Content-Type: text/html; charset=iso8859-15
>   Transfer-encoding: chunked
>   Connection: close
> (Length: not specified [text/html])
>
> I think we should somehow solve this and compute a correct Content-Length,
> reconsidering also the note from Stephen concerning open bug nr. 1377059.
>


Yeah, I don't think chunked encoding is the real answer here...

>From your explanations of encodings, it sounds like you've got a real
handle on this!  A lot of nice debugging and testing there too.  If
you turn that into some real tests and put them in tests/ecoding.test,
I'll give you a big kiss!

Re the open bug: I'm pretty sure removing the shortcut for utf-8 will
fix it, but I'm having trouble writing tests to prove it!

Attached are some tests I was working on (ouch!) 4 months ago...  Big
kisses all round for anyone who can figure this out.

Re: [naviserver-devel] Bug in upload stats

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

My bad :-(( Can you fix it, i cannot for some reason login into CVS over ssh

Stephen Deasey wrote:
> In nsd/driver.c:NsTclUploadStatsObjCmd
> 
>     while (drvPtr != NULL) {
>         Tcl_HashEntry *hPtr;
>         spPtr = &drvPtr->spooler;
>         Ns_MutexLock(&spPtr->lock);
>         hPtr = Tcl_FindHashEntry(&spPtr->table, Tcl_GetString(objv[1]));
>         if (hPtr != NULL) {
>             Sock *sockPtr = (Sock *)Tcl_GetHashValue(hPtr);
>             UploadStats *statsPtr = &sockPtr->upload;
>             sprintf(buf, "%lu %lu", statsPtr->length, statsPtr->size);
>             break;
>         }
>         Ns_MutexUnlock(&spPtr->lock);
>         drvPtr = drvPtr->nextPtr;
>     }
> 
> If the command is successful in finding the correct stats, the loop is
> exited with break.  In this case, the mutex is never unlocked, right?
> 
> No tests...  :-(
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> 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] Bug in upload stats

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

In nsd/driver.c:NsTclUploadStatsObjCmd

    while (drvPtr != NULL) {
        Tcl_HashEntry *hPtr;
        spPtr = &drvPtr->spooler;
        Ns_MutexLock(&spPtr->lock);
        hPtr = Tcl_FindHashEntry(&spPtr->table, Tcl_GetString(objv[1]));
        if (hPtr != NULL) {
            Sock *sockPtr = (Sock *)Tcl_GetHashValue(hPtr);
            UploadStats *statsPtr = &sockPtr->upload;
            sprintf(buf, "%lu %lu", statsPtr->length, statsPtr->size);
            break;
        }
        Ns_MutexUnlock(&spPtr->lock);
        drvPtr = drvPtr->nextPtr;
    }

If the command is successful in finding the correct stats, the loop is
exited with break.  In this case, the mutex is never unlocked, right?

No tests...  :-(

[naviserver-devel] Timeout in DriverRecv?

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

The nssock driver does this:

    case DriverRecv:
        timeout.sec = sock->driver->recvwait;
        n = Ns_SockRecvBufs(sock->sock, bufs, nbufs, &timeout);
        break;
    case DriverSend:
        timeout.sec = sock->driver->sendwait;
        n = Ns_SockSendBufs(sock->sock, bufs, nbufs, &timeout);
        break;

...which is called by the driver thread to read the request, headers
etc.  It's a non-blocking socket, so why the timeout?

Ns_SockRecvBufs looks like this:

    n = SockRecv(sock, bufs, nbufs);
    if (n < 0
        && ns_sockerrno == EWOULDBLOCK
        && Ns_SockTimedWait(sock, NS_SOCK_READ, timeoutPtr) == NS_OK) {
        n = SockRecv(sock, bufs, nbufs);
    }
    return n;

i.e. if on the first attempt to read from the socket the kernel returns
EWOULDBLOCK, wait for 30 seconds for something to arrive.

Sockets only return EWOULDBLOCK if they are in non-blocking mode, and
there is nothing to read/write. It's in non-blocking mode because we
want to multiplex all sockets efficiently in the driver thread.

Ns_SockTimedWait calls poll() with a timeout. It doesn't return until
data arrives or the timeout expires. So, this can block the driver
thread for up to 30 seconds.

Does this make any sense?

It's hard to see how this would be triggered in practice. We only
attempt to read from the socket if the poll loop indicates the socket is
readable. However, the Linux man page for select() (which also applies
to poll) does say:

        Under Linux, select() may report a socket file descriptor as
        "ready for reading", while nevertheless  a  subsequent  read
        blocks.  This could  for  example  happen  when  data has
        arrived but upon examination has wrong checksum and is
        discarded. There may be other circum-stances.  Thus it may be
        safer to use O_NONBLOCK on sockets that should not block.

We do use O_NONBLOCK, but then defeat that with an extra 30 second
poll() timeout...

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

On 7/13/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 13.07.2006 um 23:18 schrieb Vlad Seryakov:
>
> > You are right and now i see that Naviserver does not do this right
> > because our global cache keeps strings only. It looks like waste of
> > resource now caching file contents only but ns_share uses Tcl_Objs
> > internally, so it is possible to use it instead maybe?
>
> As I said: if you move bytecodes from interp to interp, they
> get recompiled. The only way you can do that (bytecode cachbing)
> is to keep it in the same thread and interp and this is what
> Tcl procedures are already doing.
>

Right, I forgot about that.  I asked about this on the Tcl list a
couple of years ago...

When an object is byte-code compiled it's environment is taken into
account, and that affects the compiled code.  For example, many of the
built-in Tcl commands now get inlined: for, while etc.  But what if
they've been redefined by user code?

If you byte-code compile some code in one environment, then try to run
it in another, it may not work if the environments are different.  So
the Tcl core detects and prevents this.  All code is recompiled the
first time it is run in a new environment.

I was suggesting that maybe there should be a away around this as in
some cases, like ours, we specifically make sure that all interps are
identical: we create one master interp at start up and then clone it
for each new thread.  No one seemed excited by this though...

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

Am 13.07.2006 um 23:30 schrieb Stephen Deasey:

> On 7/13/06, Andrew Piskorski <at...@pi...> wrote:
>> On Thu, Jul 13, 2006 at 10:02:35PM +0100, Stephen Deasey wrote:
>>> Our caches are server-wide, not per-interp.  Server-wide caches have
>>> their values stringified.
>>
>> Must they always though?  That is also how the nsv_* commands worked,
>> but I think Zoran's tsv_* commands do special work to retain the
>> internal rep of many objects across tsv_set and tsv_get.
>>
>
> Tcl objects may reference other objects.  Think of a list.  So it's
> not enough to copy an object's internal rep, you need to follow the
> references and do a deep-copy.  That's real ugly because then you need
> to know the details of each object's internal rep.
>
> What happens when you come accross an object you don't know about?
>
> Punt, I guess: stringify it.

EXACTLY this is what tsv is doing. For "known" objects it does
a deep copy. It also allows for registering user-callbacks to
process their own objects. But if it encounters object it does
not understand, it stringifies it.

Bytecodes cannot be "magically" processed as they contain
references to literal objects which are stored per-interp
so:

    set a 1

The "1" is a literal which gets stored in the per-interp
literal table. Therefore bytecodes must be recompiled when
jumping interpreters. Which is what would hnappen all the
time in our scenario.

Hence I do not hold much about caching bytecodes.

>
> It may or may not be worth while adding per-interp caches to the cache
> code, but I'm pretty sure ADP is the way to go for Tcl page caching.

I must second that. With the extension that it may not be worth
adding per-interp/thread caches IMO.

Cheers
Zoran

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

On 7/13/06, Andrew Piskorski <at...@pi...> wrote:
> On Thu, Jul 13, 2006 at 10:02:35PM +0100, Stephen Deasey wrote:
> > Our caches are server-wide, not per-interp.  Server-wide caches have
> > their values stringified.
>
> Must they always though?  That is also how the nsv_* commands worked,
> but I think Zoran's tsv_* commands do special work to retain the
> internal rep of many objects across tsv_set and tsv_get.
>

Tcl objects may reference other objects.  Think of a list.  So it's
not enough to copy an object's internal rep, you need to follow the
references and do a deep-copy.  That's real ugly because then you need
to know the details of each object's internal rep.

What happens when you come accross an object you don't know about?

Punt, I guess: stringify it.

It may or may not be worth while adding per-interp caches to the cache
code, but I'm pretty sure ADP is the way to go for Tcl page caching.

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

Am 13.07.2006 um 23:18 schrieb Vlad Seryakov:

> You are right and now i see that Naviserver does not do this right
> because our global cache keeps strings only. It looks like waste of
> resource now caching file contents only but ns_share uses Tcl_Objs
> internally, so it is possible to use it instead maybe?

As I said: if you move bytecodes from interp to interp, they
get recompiled. The only way you can do that (bytecode cachbing)
is to keep it in the same thread and interp and this is what
Tcl procedures are already doing.

Storing Tcl-Ojb in cache makes sense only if the internal
rep does not get changed. In case of bytecodeds this will
mostly happen.

Cheers
Zoran

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

Am 13.07.2006 um 23:15 schrieb Andrew Piskorski:

> Must they always though?  That is also how the nsv_* commands worked,
> but I think Zoran's tsv_* commands do special work to retain the
> internal rep of many objects across tsv_set and tsv_get.

Yes, but only for certain "known" types of Tcl objects.
You can't cache bytecodes thread-wide because they
contain literals and they are entered per-reference
in bytecode rep. Even my tsv "tricks" will not work.
Moreover, bytecodes get re-compiled when jumping interp
so this all bytecode caching stuff is really not something
I would do from the cost/gain perspective.

The only real practical caching of bytecodes is moving
more code into Tcl procedures and putting less code in
the page itself.

Cheers
Zoran

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

You are right and now i see that Naviserver does not do this right 
because our global cache keeps strings only. It looks like waste of 
resource now caching file contents only but ns_share uses Tcl_Objs 
internally, so it is possible to use it instead maybe?

Andrew Piskorski wrote:
> On Thu, Jul 13, 2006 at 04:53:51PM -0400, Andrew Piskorski wrote:
>> On Thu, Jul 13, 2006 at 09:28:00PM +0100, Stephen Deasey wrote:
>>
>>> Except... Rob found a neat way to cheat by passing the script as an
>>> arg to a do-nothing 'for' command.  'for' compiles the script for you.
>>>  Very smart and hellish to read...
> 
>> But if that's the case, then what does any of this have to do with
>> per-thread caches?  As you said, Naviserver is already cacheing the
>> string source of *.tcl pages, so what's preventing you from using the
>> same for/eval trick Rob used, for each interp?
>> (I must be missing something here...)
> 
> Oh, the snippet of file.tcl Vlad posted talked about:
> 
>   bytecode, which will be associated with the Tcl_Obj we just cached
>   (as its internal representation).
> 
> Which maybe answers my question...  I suspect that:
> 
> The Tcl interp is able to cache and re-use the bytecode for procs,
> because the proc persists - its Tcl_Obj hangs around.  But if you hand
> the Tcl interp a script snippet (e.g., the entire contents of a *.tcl
> page), yes a Tcl_Obj is created, but as soon as you're done evaluating
> the script, that Tcl_Obj's reference count drops to zero and it goes
> away.  Thus there is no persistent Tcl_Obj around to hang the byte
> code internal-rep on unless you explicitly create one.  And, Rob used
> a per-thread (or per-interp?) ns_cache to create that persistent
> Tcl_Obj.  Something like that?
> 
> Could a Tcl namespace variable of some sort also be used to provide
> the persistant Tcl_Obj for the *.tcl script?
> 

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

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

On Thu, Jul 13, 2006 at 10:02:35PM +0100, Stephen Deasey wrote:
> Our caches are server-wide, not per-interp.  Server-wide caches have
> their values stringified.

Must they always though?  That is also how the nsv_* commands worked,
but I think Zoran's tsv_* commands do special work to retain the
internal rep of many objects across tsv_set and tsv_get.

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

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

On Thu, Jul 13, 2006 at 05:08:14PM -0400, Andrew Piskorski wrote:
> Which maybe answers my question...  I suspect that:

Doh, never mind my silly speculations, Stephen just explained now it
really works in his last post.

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

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

On Thu, Jul 13, 2006 at 04:53:51PM -0400, Andrew Piskorski wrote:
> On Thu, Jul 13, 2006 at 09:28:00PM +0100, Stephen Deasey wrote:
> 
> > Except... Rob found a neat way to cheat by passing the script as an
> > arg to a do-nothing 'for' command.  'for' compiles the script for you.
> >  Very smart and hellish to read...

> But if that's the case, then what does any of this have to do with
> per-thread caches?  As you said, Naviserver is already cacheing the
> string source of *.tcl pages, so what's preventing you from using the
> same for/eval trick Rob used, for each interp?
> (I must be missing something here...)

Oh, the snippet of file.tcl Vlad posted talked about:

  bytecode, which will be associated with the Tcl_Obj we just cached
  (as its internal representation).

Which maybe answers my question...  I suspect that:

The Tcl interp is able to cache and re-use the bytecode for procs,
because the proc persists - its Tcl_Obj hangs around.  But if you hand
the Tcl interp a script snippet (e.g., the entire contents of a *.tcl
page), yes a Tcl_Obj is created, but as soon as you're done evaluating
the script, that Tcl_Obj's reference count drops to zero and it goes
away.  Thus there is no persistent Tcl_Obj around to hang the byte
code internal-rep on unless you explicitly create one.  And, Rob used
a per-thread (or per-interp?) ns_cache to create that persistent
Tcl_Obj.  Something like that?

Could a Tcl namespace variable of some sort also be used to provide
the persistant Tcl_Obj for the *.tcl script?

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

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

Am 13.07.2006 um 22:53 schrieb Andrew Piskorski:

>
>> Right, output caching is a different thing.  But wouldn't it be cool
>> to have it working for ADP pages, Tcl pages, registered procs etc.?
>
> Yes, indeed it would...

Do not forget that you get caching for free if you just
move bulk of the code in Tcl procedures. First time they are run,
they get byte-compiled.
Just my 2 cents.

Cheers
Zoran

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

On 7/13/06, Andrew Piskorski <at...@pi...> wrote:
> On Thu, Jul 13, 2006 at 09:28:00PM +0100, Stephen Deasey wrote:
>
> > Except... Rob found a neat way to cheat by passing the script as an
> > arg to a do-nothing 'for' command.  'for' compiles the script for you.
> >  Very smart and hellish to read...
>
> Ok, some Tcl commands cause their script arguments to be compiled to
> bytecode, others simply interpret them directly.  And Tcl interps
> automatically cache their own bytecode as necessary.
>
> So...  Are you saying that Rob changed AOLserver 3.x such that it used
> 'for' rather than 'eval' (or whatever else) to run the code in *.tcl
> files?  And THAT made all the difference, because as long as the *.tcl
> file had not changed, the Tcl interp would automatically find and use
> the bytecode it had already created the first time that particular
> *.tcl file was run?


No, it uses eval at runtime.  But the object to be evaled already has
it's byte code representation.  The byte code is generated as the
object is put into the cache.


> But if that's the case, then what does any of this have to do with
> per-thread caches?  As you said, Naviserver is already cacheing the
> string source of *.tcl pages, so what's preventing you from using the
> same for/eval trick Rob used, for each interp?
> (I must be missing something here...)
>


Our caches are server-wide, not per-interp.  Server-wide caches have
their values stringified.

AOLserver 4.5 has the same restriction with it's new ns_cache
implementation, btw.

We talked about adding per-interp caches.  It's not a high priority
for me as I think converting to use the ADP code is the best solution,
for the reasons mentioned before.

Re: [naviserver-devel] Cache compiled Tcl page bytecode

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

On Thu, Jul 13, 2006 at 09:28:00PM +0100, Stephen Deasey wrote:

> Except... Rob found a neat way to cheat by passing the script as an
> arg to a do-nothing 'for' command.  'for' compiles the script for you.
>  Very smart and hellish to read...

Ok, some Tcl commands cause their script arguments to be compiled to
bytecode, others simply interpret them directly.  And Tcl interps
automatically cache their own bytecode as necessary.

So...  Are you saying that Rob changed AOLserver 3.x such that it used
'for' rather than 'eval' (or whatever else) to run the code in *.tcl
files?  And THAT made all the difference, because as long as the *.tcl
file had not changed, the Tcl interp would automatically find and use
the bytecode it had already created the first time that particular
*.tcl file was run?

But if that's the case, then what does any of this have to do with
per-thread caches?  As you said, Naviserver is already cacheing the
string source of *.tcl pages, so what's preventing you from using the
same for/eval trick Rob used, for each interp?
(I must be missing something here...)

> > > I think the way to go here is to merge Tcl pages in with the ADP page
> > > code.  What's the difference between an ADP page like this:
> >
> > What would that accomplish?  Is there already cacheing of the
> > bytecodes of Tcl source included in ADP pages?
> 
> Yes.  And also, the bit below...

> Right, output caching is a different thing.  But wouldn't it be cool
> to have it working for ADP pages, Tcl pages, registered procs etc.?

Yes, indeed it would...

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

Re: [naviserver-devel] Why was NaviServer forked?

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

Am 13.07.2006 um 19:39 schrieb Andrew Piskorski:

>
> A silly thing to lose half or so of AOLserver's active core developers
> over, and a silly thing to fork over as well...  All IMO, of course.
>

Do not unerestimate the AOLserver gatekeeper species!
One (KH) spawned OpenNsd. The other Naviserver...
After all, that one did made at least 3 persons really
angry. The chance that all three of them are weirds is
there, but not that high, I would say ;-)

I see this so: if you are driving a car, you must
look forward, otherwise you hit the wall. So, whatever
*was* is secondary. It turned out this way and we now
have what we have (or have not)...

Cheers,
Zoran