> 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