There is no infrastructure for interprocess notifications in
nginx right now. Basically it’s the reason why there is no such
things as busy locks and so on.
You may try to emulate it via e.g. message queue in shared memory
and periodic timer in each worker process to check it. It’s not
perfect, but probably will work for you.
location request handler in a module. (maybe using ngx_channel
perfect, but probably will work for you.
Maxim D.
What about using ngx_add_channel_event on process initialization?
Is there anything obviously wrong with doing something like the
following:
/in init process callback/
ngx_socket_t my_channel=ngx_channel;
/* is that the correct socket? what about
ngx_processes[ngx_process_slot].channel[0] and
ngx_processes[ngx_process_slot].channel[1] ?
which could be used?
*/
if (ngx_add_channel_event(cycle, my_channel, NGX_READ_EVENT,
ngx_http_push_channel_handler) == NGX_ERROR) {
exit(2);
}
//…
FYI, and for anyone else encountering this problem, I ended up rolling
my own socketpairs and reusing some of the existing channel handling
functions. One caveat that I did notice:
The number of worker processes is needed before nginx fork()s. You
can get this in your module’s initialization handler from
((ngx_core_conf_t *) ngx_get_conf(cycle->conf_ctx,
ngx_core_module))->worker_processes;
In any other module handler it will either be too early or too late to
access this data.
On Mon, Oct 19, 2009 at 05:18:12PM -0400, Leo P. wrote:
location request handler in a module. (maybe using ngx_channel
ngx_processes[ngx_process_slot].channel[1] ?
which could be used?
*/
[…]
Socket pairs in question are used for nginx’s own needs (control
commands from master to workers). Any attempt to reuse them will
case nginx malfunction at next control command.
Eventually this will grow into something more generic and modules
will be able to use this for their own commands. But it’s not here
yet.
Maxim D.
p.s. BTW, just to make sure you know: nginx_http_push_module
relies on shared memory as something unconditionally available for
all processes, but this isn’t really true during binary upgrades.
New binary creates their own shared memory zones from scratch. As
a result - module won’t survive binary upgrades flawlessly but
will loose messages instead.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.