Le jeudi 01 mai 2008 à 11:39 +0200, Manlio Perillo a écrit :
Each variable will be correct, but since you are writing the value to a
shared memory location not atomically, the variable as read by the
client will not be correct.
Yes, I'm aware of this, but at this time I don't know which system calls
to use to be compatible with other OSes, so assume there will be a
critical section (for example a mutex/spin lock in shared memory) and
that the script must use it prior reading data.
Moreover it really does not make sense to write in a shared memory if
you want to support monitoring tools!
Just write a module like the stub_status module!
Sorry, but I do not understand what you mean. I just want to provide
something like /proc (on Linux) which is used by many monitoring tools.
Finally there is one last problem.
Nginx uses only a few shared variables (the one handled the the
All other variables are private to each worker process.
This means that probably your shared memory location will contain values
not very useful.
I agree. It's why I provide a very simple API to help migrating useful
data to the monitoring area, of course it's not transparent and
variables need to be ngx_atomic_t, not private. But that way it will be
easy to add monitoring support if *needed*.
For example gzip compress ratio can be compared to CPU use in mid/long
term; should I use gzip level 9 or 1 for *my* application?
It could be done if modules provide the possibility to monitor useful
variables if needed. It's a framework with a very low hit on
performance; I can change the API in such way that if monitoring is not
enabled, then the module will know that it should use private variable
instead of ngx_atomic_t, but I agree it's not completly transparent.
Thank you for your input, I'm listening and it's open ;-)