naviserver-devel — Developer discussion

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

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

> 
> Communication between serialized threads doesn't sound like a cache to me.
> Anyway, the idea is that if you need to do weird stuff it should be
> possible, and an ns_cache_info equivalent can be writen in ~3 lines of
> Tcl.

Very sad.

I'd suggest we define what is weird and what is not first.

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

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

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

On 6/25/06, Vlad Seryakov <vl...@cr...> wrote:
> >
> > If you need to test for existence, you're doing something wrong.
> > Between the test and the action taken depending on the result, the
> > result could have changed.
> >
> > However:
> >
> >    ns_cache_eval $cache $key {error "no entry available"}
> >
> > You can catch the error and do whatever, no new entry will be created.
>
> Again, you assuming only one way of using caches, in my case i am not
> afraid what happens in between because, i just need to know if somebody
> put anything in the cache, similar to flag. Very simple test, and does
> not need to generate and cache error exception which will make Tcl doe
> look ugly. That's why we have info exists in Tcl instead of error
> handling if we need to test existence.
>
> >
> >> And why ns_cache_eval -force is not racy but than ns_cache_set is if
> >> they do the same thing, why cryptic API flags instead of clear
> >> functions. If have them for nsv_ for example.
> >
> >
> > It depends how you use them.  The use case of pre-filling a cache in
> > bulk at start up for example might be a good use of this.  In combo
> > with _info is not.  The -force switch was a ~3 line addition.
>
> Right, so it is up to the developer to decide how to use primitive cache
> routines, and i never said i use _info first then _set next, but i can
> see it may be used in environment where serialized jobs are running in
> different threads and i need to know what previous job have done. In
> this case _info then _set or _get is pretty valid, it uses cache as a
> storage in non-concurrent environment.

Communication between serialized threads doesn't sound like a cache to me.

Anyway, the idea is that if you need to do weird stuff it should be
possible, and an ns_cache_info equivalent can be writen in ~3 lines of
Tcl.

Re: [naviserver-devel] ns_cache is still broken

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

I also have question what is the meaning of changing -ttl 
relativeSeconds into -expires absolutetime.

Now Tcl code looks bloated with all -expires [expr [ns_time]+3600] lines 
not counting that this is much slower than doing such incrementing C.

May be we can keep both parameters, -ttl as relative and -expires as 
absolute?

Zoran Vasiljevic wrote:
> Am 27.06.2006 um 14:16 schrieb Zoran Vasiljevic:
> 
>> This might be if the default value of cacheTimeout of 3 seconds
>> is simply too low for the operation of caching the element in
>> ns_cache_eval.
> 
> I think that this was the problem. So after increasing from 3 to 60
> secs, the problems went away.
> 
> I believe we will have to find some consensus about what and how
> we expect this cache stuff to work.
> 
> For me, I'm OK with everything, as long as it computes!
> Stephen, you are the major moving force behind this module.
> Can you get us the direction you'd like to follow and let
> us see how we can go there?
> 
> 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/

Re: [naviserver-devel] ns_cache is still broken

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

> I believe we will have to find some consensus about what and how
> we expect this cache stuff to work.
> 
> For me, I'm OK with everything, as long as it computes!
> Stephen, you are the major moving force behind this module.
> Can you get us the direction you'd like to follow and let
> us see how we can go there?

And i would like to add that i need this cache implementation includes
per-cache timeouts and exists command (i can live with ns_cache_eval -force)

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

Re: [naviserver-devel] ns_cache is still broken

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

Am 27.06.2006 um 14:16 schrieb Zoran Vasiljevic:

> This might be if the default value of cacheTimeout of 3 seconds
> is simply too low for the operation of caching the element in
> ns_cache_eval.

I think that this was the problem. So after increasing from 3 to 60
secs, the problems went away.

I believe we will have to find some consensus about what and how
we expect this cache stuff to work.

For me, I'm OK with everything, as long as it computes!
Stephen, you are the major moving force behind this module.
Can you get us the direction you'd like to follow and let
us see how we can go there?

Cheers
Zoran

Re: [naviserver-devel] Tcl async cancel

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

I agree, it is just sometimes useful to cancel long running Tcl thread 
instead of restarting the whole server. It will tell you when it stuck 
and you can fix that problem later, it is not for daily use of course.

Zoran Vasiljevic wrote:
> Am 28.06.2006 um 19:06 schrieb Vlad Seryakov:
> 
>> i am porting Tcl Async cancelation from AOlserver 4.5 if nobody  
>> objects,
>> this is great feature
> 
> Hm... I do not object, but why is this great?
> The cancellation is always the worst possible thing
> you can do. This means that the code is inherently
> broken. But if you have any use for it, go ahead.
> 
> 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/

Re: [naviserver-devel] Tcl async cancel

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

Am 28.06.2006 um 19:06 schrieb Vlad Seryakov:

>
> i am porting Tcl Async cancelation from AOlserver 4.5 if nobody  
> objects,
> this is great feature

Hm... I do not object, but why is this great?
The cancellation is always the worst possible thing
you can do. This means that the code is inherently
broken. But if you have any use for it, go ahead.

Cheers,
Zoran

[naviserver-devel] Tcl async cancel

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

Hi,

i am porting Tcl Async cancelation from AOlserver 4.5 if nobody objects, 
this is great feature


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

Re: [naviserver-devel] 64bit

[Bernd E. <eid...@we...>]

> Some of our customer do. Yet, module-wise they use only NS common
> modules (nslog, nssock, nsperm...) plus number of our proprietary
> modules on SuSE 64bit Linux box.

Our provider set up a new system with 64bit unaskedly, I ordered 32bit. 
I don't want to run into any open or hidden traps - now or later. I guess it's 
more safe to insist on the 32bit version now, as I have no machine around to 
test in the moment.

Bernd.

Re: [naviserver-devel] 64bit

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

Am 28.06.2006 um 07:33 schrieb Bernd Eidenschink:

> Does one of you use Naviserver with common modules on a 64bit  
> architecture?
> On a production system?

Some of our customer do. Yet, module-wise they use only NS common
modules (nslog, nssock, nsperm...) plus number of our proprietary
modules on SuSE 64bit Linux box.

Cheers
Zoran

[naviserver-devel] 64bit

[Bernd E. <eid...@we...>]

Hi! 

Does one of you use Naviserver with common modules on a 64bit architecture?
On a production system?

Thanks,

Bernd.

Re: [naviserver-devel] ns_cache is still broken

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

On 6/27/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 27.06.2006 um 18:15 schrieb Stephen Deasey:
>
> >
> > There's no default timeout in the current code, and the error
> > message should be:
> >
> >     timeout waiting for concurent update: ...
> >
> > Make sure you're testing code from HEAD.
>
> Easier said than done. The HEAD is not usable for testing
> as the code we have on the customer site is dated prior to
> your recent changes to ns_cache. Hence I must look in the
> code before that and try to understand if there is still
> something wrong OR the timeout of 3 seconds is just to low.
>
> We will have to maintain a separate internal branch until
> all this noise on ns_cache settles down and we are again
> all confident that it works as wanted/expected. Recent
> changes made it incompatible with the rest of the code and
> we can't make changes there for some time.
>

OK.  Just checking.

Re: [naviserver-devel] ns_cache is still broken

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

Am 27.06.2006 um 18:15 schrieb Stephen Deasey:

>
> There's no default timeout in the current code, and the error  
> message should be:
>
>     timeout waiting for concurent update: ...
>
> Make sure you're testing code from HEAD.

Easier said than done. The HEAD is not usable for testing
as the code we have on the customer site is dated prior to
your recent changes to ns_cache. Hence I must look in the
code before that and try to understand if there is still
something wrong OR the timeout of 3 seconds is just to low.

We will have to maintain a separate internal branch until
all this noise on ns_cache settles down and we are again
all confident that it works as wanted/expected. Recent
changes made it incompatible with the rest of the code and
we can't make changes there for some time.

Cheers,
Zoran

Re: [naviserver-devel] ns_cache is still broken

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

On 6/27/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 27.06.2006 um 13:33 schrieb Zoran Vasiljevic:
>
> > Hi !
> >
> > I got the same report from customers:
> >
> >    timeout waiting for update: 59331.0.n.childs
> >
> > We never use anything except ns_cache_create, ns_cache_flush
> > and ns_cache_eval commands.
>
> This might be if the default value of cacheTimeout of 3 seconds
> is simply too low for the operation of caching the element in
> ns_cache_eval. I believe that this default value is too low.
> I have instructed the customer to increase the value from 3 to
> 60 secnds and observe the operation. At the same time I'm analyzing
> the code once more... Soon I will know everything by heart..


There's no default timeout in the current code, and the error message should be:

    timeout waiting for concurent update: ...

Make sure you're testing code from HEAD.

Re: [naviserver-devel] ns_cache is still broken

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

Am 27.06.2006 um 13:33 schrieb Zoran Vasiljevic:

> Hi !
>
> I got the same report from customers:
>
>    timeout waiting for update: 59331.0.n.childs
>
> We never use anything except ns_cache_create, ns_cache_flush
> and ns_cache_eval commands.

This might be if the default value of cacheTimeout of 3 seconds
is simply too low for the operation of caching the element in
ns_cache_eval. I believe that this default value is too low.
I have instructed the customer to increase the value from 3 to
60 secnds and observe the operation. At the same time I'm analyzing
the code once more... Soon I will know everything by heart..

Cheers,
Zoran

[naviserver-devel] ns_cache is still broken

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

Hi !

I got the same report from customers:

   timeout waiting for update: 59331.0.n.childs

We never use anything except ns_cache_create, ns_cache_flush
and ns_cache_eval commands.

This kind of error was happening much more often before and
I have tried to fix that bug some days ago. Aparently I found out
that due to the bug in cache.c, we always have expired the
cached entry and the ns_cache_eval was just re-caching it all
the time. This obviously exposed the problem more often
than now, as this bug is fixed. But, the "real" bug is still
lurking there. This means that if you do not use timed caches,
your program might get stucked in the cache code forever.
Again: this might not happen to you in million years but it can
happen the very next millisecond...
I cannot get any decent test to expose this bug, as this is
obviously some race condition in the code. I hope to be able
to get that working today, by reading the code and trying to
understand what it does. Please excuse me if I do some "non-optimal"
changes to get it working properly. At the moment, the correct
operation is paramount to us whereas speed/performance is not.

Cheers,
Zoran

Re: [naviserver-devel] SVN

[Bernd E. <eid...@we...>]

Hi Vlad,

> I noticed some projects(gaim for example ) already using svn on SF. Can
> we switch to svn as well?

I wrote this already to the list during the SF mail problems so maybe you have 
it already:
* SVN was developed from scratch, 
* the repository is based on Berkeley DB, 
* you don't need repository access for diffs etc., 
* SVN sets a new revision number for the whole project after every commit, 
* version control for directories (copy, move, add, delete, mkdir),
* transactions with rollbacks, 
* more protocols to access repositories (svn, svn+ssh, file, http 
[apache2+webdav], https), 
* cheap copy when creating branches and tags (a tag is simply a "copy" of e.g. 
a directory hierarchy using almost no space until you branch), 
* nice handling of binary files (everything is "binary" and you can set/change 
mimetypes), 
* explicit setting of keywords you want to use (like "Id").

Just try "cvs2svn" or take a look here:
http://www.onlamp.com/pub/a/onlamp/2005/10/03/cvs-to-subversion-with-cvs2svn.html

As long as we have the CVS repos it should be safe to play with cvs2svn. We 
use SVN in the company since early 1.0 release and never wanted to revert 
back to CVS. Of course, not everything is sugar and creme, but as many things 
are similar to CVS you don't have to learn all too much.
I recommend ISBN 3-89842-603-3.

Bernd.

[naviserver-devel] SVN

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

I noticed some projects(gaim for example ) already using svn on SF. Can 
we switch to svn as well?

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

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

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

> 
> Adding without restraint is also a problem.  It gets to the point
> where you code yourself to a stand still.  For example, there are some
> long standing bugs in the driver code which have been looked at and
> are still failing tests.  Essentially, they are unfixable.

We discussed driver extensions and i offered more than year ago what 
could work and it is working fine, i've been using that extensions all 
the time and now. We agreed until something better will appear i will 
keep this driver code. As for failing tests, in real life the code works 
but with this tests not so it is still unclear why. I use upload/writer 
threads in pretty busy environment so it is not completely bad but 
again, do not just wipe them out, let's discuss what you can offer 
instead of this keeping the functionality of course.

> Here's a recent example:
> 
> The routine Ns_SockTimeWait was changed so that if NULL is passed as
> the timeout, it just polls.  All the other calls in the server which
> take a timeout parameter, NULL mean infinite wait, not no wait.
> 
> If you look at the context in which this is used, SockTimedWait is
> used to ask the question "is this socket writeable?".  There is no
> wait, for any amount of time.  It makes the code very hard to read,
> especially in combination with similar changes.

I checked the code and previously Ns_SockTimeWait could not accept NULL, 
it assumed that it is always passed, so adding NULL was safe, but i 
agree, passing 0 timeout would do the same purpose and adding NULL as 
infinite would be more logical.

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

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

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

> 
> If you need to test for existence, you're doing something wrong.
> Between the test and the action taken depending on the result, the
> result could have changed.
> 
> However:
> 
>    ns_cache_eval $cache $key {error "no entry available"}
> 
> You can catch the error and do whatever, no new entry will be created.

Again, you assuming only one way of using caches, in my case i am not 
afraid what happens in between because, i just need to know if somebody 
put anything in the cache, similar to flag. Very simple test, and does 
not need to generate and cache error exception which will make Tcl doe 
look ugly. That's why we have info exists in Tcl instead of error 
handling if we need to test existence.

> 
>> And why ns_cache_eval -force is not racy but than ns_cache_set is if
>> they do the same thing, why cryptic API flags instead of clear
>> functions. If have them for nsv_ for example.
> 
> 
> It depends how you use them.  The use case of pre-filling a cache in
> bulk at start up for example might be a good use of this.  In combo
> with _info is not.  The -force switch was a ~3 line addition.

Right, so it is up to the developer to decide how to use primitive cache 
routines, and i never said i use _info first then _set next, but i can 
see it may be used in environment where serialized jobs are running in 
different threads and i need to know what previous job have done. In 
this case _info then _set or _get is pretty valid, it uses cache as a 
storage in non-concurrent environment.

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

Re: [naviserver-devel] RFE: Expanding ns_log/ns_logctl

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

Am 25.06.2006 um 14:41 schrieb Stephen Deasey:

>
> Take a look at log4j by the apache project.  This is very popular and
> seems to have inspired a lot of imitators such as log4py, log4c etc.
> Maybe log4c has a better API than the old Ns_ModLog stuff.
>

I did. This is exactly what I thought: they use "kind of" facility
as a hierarchical thing, like some.log.thing which of course
requires you to obtain the logger which knows how to produce
log for some.log-thing and then use that logger to log the entry.
In procedural types of languages we'd need to

   ns_log some-log.thing info "This is the info log"

but this would be backwardly incompatible and would mean total
departure of what we have now.

Consider this stupid little example:

   proc add {a b} {
      if {$a == 0 || $b == 0} {
         ns_log warning "add: one argument is zero"
      }
   }

Whenever/whereever/whoever calls "add" will eventually
produce one warning log line in the common log file.
At the level of the "add" procedure I do not know anything
about log facility for which I'm to emit the log line i.e.
I do not know anything about the calling context.
Hence, this is very simple to use.

If I have 20 threads doing completely separate calculations
and I would like to isolate this log line for just a
bunch of them (i.e. ones within the "some context")
I could do:

   ns_logctl register add_log whatever_id

The add_log procedure must now be clever enough to
"know" what to do for different "whatever_id" arguments.
In the above case, it might somehow obtain the current
value of the ID (whatever that is) in the current thread
and compare it with the passed argument.

So I'm *purposely* building the logic into the callback
and *not* into the server as this will be backward-compatible
for tons of existing code. And, it is much simpler to use
as I do not have to care about the calling context (or facility)
when writing ns_log lines. IOW, I can add the notion of the
"context" from the outside.

The main idea is: as simple as possible, backward-compatible
(no api changes to existing code), ability to route parts of
the global logs to separate log sinks for a "task" which is
potentially executed by number of threads. Every thread should
be able to isolate a "task" by calling some "gettaskid" procedure
which is entirely out of the scope of the log machinery, of course.

I'm sure that we can rewrite the log part to be much more
"fancy" but what we have now (ns_log) serves the purpose
very well and does not require me to think about the calling
context. The only drawback is the lack of finer granularity
as what goes where. I have tried to fill in that hole by
being mininally invasive on the API level.

Now, what do you think?

Cheers
Zoran

Re: [naviserver-devel] RFE: Expanding ns_log/ns_logctl

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

Am 25.06.2006 um 14:41 schrieb Stephen Deasey:

> If you add facility, you could:
>
>   ns_logctl register $facility $priority joblog ?arg ...?
>
> The filtering would be done by the server, rather than the callback.
> You're focusing on sinks here, but you need a way to distinguish what
> goes where, and facility levels seem like such a standard thing.  It
> would enable you to turn on verbose logging for just one area of code,
> which would reduce log spam.
>
> Take a look at log4j by the apache project.  This is very popular and
> seems to have inspired a lot of imitators such as log4py, log4c etc.
> Maybe log4c has a better API than the old Ns_ModLog stuff.

In this case, the ns_log call will also have to change as in:

   ns_log facility severity arg ?arg...?

or?

If this is true, then I would not like to do that, as one of
my main targets is: keep the changes to the existing code
as minimal as possible.
For example, I can wrap one of our internal procedures
which calls 100's of other, which in turn already use
ns_log (and Ns_Log()) to fill-in the log file:

   ns_logctl register backup_log [getjobid]
   backup [getjobid]
   ns_logctl unregister backup_log

This way all ns_log's called between those two ns_logctl will
emit log entries not only to the global server logfile but also
where backup_log procedure will send them. I need not modify
ANY other places in the code.

Does this compute? Or did I misunderstand your idea?

Cheers,
Zoran

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

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

Am 25.06.2006 um 14:57 schrieb Stephen Deasey:

>
> Here's a question though: if you have URL limits and per cache limits,
> which takes precedence?

Good question!

As I'm reading your response I now get the idea where you're
heading. This makes much sense if you have a very clear idea
what your "job" is.

In the case of fetching a dynamic page, the "job" is clear:
it is the time between the start of request and the time
when the last byte of the page is returned. This is more-less
the main job of an web-server.

But in the case of an arbitratry call to some long-running
procedure, as in application server(s), things become complicated
as "job" is difficult to define. You can think of a job as a
procedure call or call to a predefined sequences of procedures,
or... what??

Take for example our application which uses NS as a general
purpose application server. It starts a "job" of saving couple
of TB of user data on some tape media. Underneath this is just
a procedure call. But inside, we start numerous threads, call
100's of internal subprocedures, do socket comm to several
other instances of NS running on other hosts etc...
We use all sorts of internal timeouts there. Yet, we do not try
to sum them all and project a time in future when a "job" should
finish! We do not know when that will be, as million things can
come in between. I will not go into more detail because I'm sure
you understand what I mean.

I must say that I will have to re-think twice or more the idea
you are proposing and see how this will affect us, as this is
not trivial. And it is not compatible to any code we have running
now. The idea itself seems very appealing but I have headaches
when I start to think about implications... :-(

Cheers
Zoran

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

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

On 6/21/06, Vlad Seryakov <vl...@cr...> wrote:
> > We talked about this before.  If I remember correctly, you didn't
> > disagree with me that the commands were racy, you said you code base
> > was large and you didn't have time to figure out what you really
> > needed.
> > More and more unnecessary code is being added.  Things are getting out
> > of control.  However, you'll notice that I did not just remove
> > everything.  With the new -force switch to ns_cache_eval, _set, _get,
> > and _info can be trivially emulated in a couple of lines of Tcl, if
> > you want that kind of racy behaviour.
>
> > Everything is of course still available via the C api, and I'd
> > recommend taking a look at what your real requirements are and
> > building accordingly.  If it can be generalised, we can get it into
> > the core.
> >
> > The timeout in the aolserver implementation refers to just the time
> > waiting for a conn thread.  I'm going to extend that to mean total
> > time allowed for the conn to run.
> >
> > To get this working, Ns_Conn structs need to be allocated in driver.c,
> > not queue.c as they are now.  driver.c is looking a little scary...
> >
>
> By reading this i got an impression that i should expect in the future
> one day that CVS HEAD is completely re-written, all parts that you think
> are
> unnecessary or not correspond to your requirements are removed. And this
> can happen even without warning. Looks like you have big plans for all
> parts already. You should have asked us before removing parts that are
> in the source for several months already.
>
> I would suggest for all of us to define how we do development and
> respect each others rights and ability to extend server.
>


Adding without restraint is also a problem.  It gets to the point
where you code yourself to a stand still.  For example, there are some
long standing bugs in the driver code which have been looked at and
are still failing tests.  Essentially, they are unfixable.

Here's a recent example:

The routine Ns_SockTimeWait was changed so that if NULL is passed as
the timeout, it just polls.  All the other calls in the server which
take a timeout parameter, NULL mean infinite wait, not no wait.

If you look at the context in which this is used, SockTimedWait is
used to ask the question "is this socket writeable?".  There is no
wait, for any amount of time.  It makes the code very hard to read,
especially in combination with similar changes.



.

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

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

On 6/21/06, Vlad Seryakov <vl...@cr...> wrote:
> >
> > We talked about this before.  If I remember correctly, you didn't
> > disagree with me that the commands were racy, you said you code base
> > was large and you didn't have time to figure out what you really
> > needed.
>
> That was about tls not cache
>
> > More and more unnecessary code is being added.  Things are getting out
> > of control.  However, you'll notice that I did not just remove
> > everything.  With the new -force switch to ns_cache_eval, _set, _get,
> > and _info can be trivially emulated in a couple of lines of Tcl, if
> > you want that kind of racy behaviour.
>
> Here is the thing, if i need to test for entry existence in the cache i
> need touse ns_cache_eval which will create this entry, same with
> ns_cache_get, why do i have to create it when i want to test existence
> only, info exists does not create Tcl variables


If you need to test for existence, you're doing something wrong.
Between the test and the action taken depending on the result, the
result could have changed.

However:

   ns_cache_eval $cache $key {error "no entry available"}

You can catch the error and do whatever, no new entry will be created.


> And why ns_cache_eval -force is not racy but than ns_cache_set is if
> they do the same thing, why cryptic API flags instead of clear
> functions. If have them for nsv_ for example.


It depends how you use them.  The use case of pre-filling a cache in
bulk at start up for example might be a good use of this.  In combo
with _info is not.  The -force switch was a ~3 line addition.