[BF] slab init + http file cache fixes
serg.brester at sebres.de
Thu Jun 16 11:29:04 UTC 2016
> 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)?
> 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:
My foot! It's just embarrassing, if it was a respond to critique (imho
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...
More information about the nginx-devel