The NGX_HTTP_CACHE_SCARCE is intended to signal to the caller that
min_uses was not yet reached, and that's why the request will not
use cache. And that's the only case where NGX_HTTP_CACHE_SCARCE
is used. Semantics of the error case your are trying to add here
is quite different. This will be an immediate problem if/when
we'll add appropriate $upstream_cache_status value for SCARCE.
(Moreover, I'm not really sure this needs fixing at all, as since
version 1.9.13 cache manger monitors number of elements in the
cache and tries to avoid cache zone overflows. That is, overflows
are not expected to happen often.)
I think, I had clearly described my position to that: always better to
process the request as to fail it, just because cache is sometimes
exceeded. And I had such situation several times, so cache manger was
apparently not succeeded by very intense load.
Race condition here is intended: we are dropping the lock to
prevent lock contention during a potentially long syscall. It is
expected that in some cases another worker will be able to grab
the node, and this will prevent its complete removal. But there
is more than one case possible: e.g., another worker can grab the
node and put an updated file into it before the file will be
deleted, and as a result we'll delete different file here. The
question is: what is the case you are trying to improve, and what
it means for other possible cases.
As I already wrote, it happened without this fix.
The "cache->files" is used to count number of files processed by
the cache loader. When it reaches loader_files, cache loader will
sleep for a while. There is nothing wrong that it is incremented -
as the file was processed, it should be incremented. With the
change in question cache loader won't be able to properly respect
loader_files and loader_threshold, making it use all available
resources in case of errors.
Well, I do not insist here.
... win32 ...
If you think this problem can be seen on other platforms - feel
free to point them out as well.
For which purposes? Thus the message contains "win32"? Really?
Just to not harry mere any statistics, that says nginx (and nginx+) have
no bugs (under *nix)?
No, sorry...
If you can suggest a better name - please do so.
If I would have better name, I had used it right away.
We certainly don't want to try to preserve compatibility with
someone who in theory can use slab code outside of nginx. If
somebody really does so, it can add appropriate initialization.
Agreed, I do not insist here.
You may find this article interesting:
http://blog.flaper87.org/post/opensource-owes-you-everything-and-nothing/
My foot! It's just embarrassing, if it was a respond to critique (imho
well-deserved critique).
I'm already longer as century quarter a developer, the same long
contribute to several projects, more than decade I'm a lead or co-owner
of many projects. Never, never I've been so a nonsense read.
But shouldn't argue about taste...
Regards,
sebres.
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
