Why named shared memory zones

Maxim Dounin mdounin at mdounin.ru
Tue Sep 29 03:26:46 MSD 2009


Hello!

On Mon, Sep 28, 2009 at 11:39:49PM +0300, Marcus Clyne wrote:

> 
> >I do not think that short syntax is good, suppose:
> >proxy_cache_path  /data/nginx/cache  1:2  ONE  10m  20m  50m;
> Sure, I can see why it could be confusing, but that's why I'm
> suggesting both as an option, and leave it up to whoever manages the
> server to decide whether they want the longer or shorter syntax.  I
> think there will be others than just myself who would prefer a
> shorter syntax as an option.
> 
> You could also write the above as
> 
> proxy_cache_path  /data/nginx/cache  1:2  ONE 10M  20m  50M
> 
> which helps to differentiate between the time and keys zone size, or
> you could have
> 
> proxy_cache_path  /data/nginx/cache  1:2  ONE:10M  20m  50M
> 
> to link the shm name with size, which might make it easier to
> remember the order if you have to.

Using more than two or three positioned arguments are error-prone 
and just silly.  It's hard to remember their intended order, it's 
impossible to change order and/or remove one of them if needed 
later for some reason, you may add new arguments to the end only, 
there is no good way to provide defaults.  In this particular case 
it will be impossible to detect some errors in arguments order, 
too (as time and size declarations may be identical.

Having two possible notations allowed will make things even worse as 
you'll have to a) remember both as administrator to be able to read 
configs b) distinguish them reliably in parsing code.

Speaking particularly about proxy_cache_path:

There was at least 2 changes in it's arguments since introduction.
With current syntax it was hardly even noticeable.  With proposed 
"short" notation it would likely require each and every config 
rewrite or introduction of another directive (with 
proxy_cache_path left as legacy).

Maxim Dounin

p.s. I understand that you want to do things better.  But 
suggested change is bad.  Really.





More information about the nginx mailing list