Hello!
On Mon, May 23, 2016 at 6:01 PM, Romaboy wrote:
> foreword:
> It's not a secret, that each worker is isolated from others. You can use
> shared.DICT or database to share data between them. Lua globals are much
> more efficient and easier to use. What if you need to make all workers
> iterate their global tables?
It seems that the shared memory queues will serve you well here:
https://github.com/openresty/lua-nginx-module/pull/586
> I need that feature and hope for help. It's for
> websoket. Yes, there is "openresty-chat" example, but it uses global table
> and only one worker.
Well, we have some production users running openresty-based websocket
pushing system leveraging ngx.semaphore and the shm queue mentioned
above serving 1,400,000+ concurrent connections in each single online
machine, enjoying all the CPU cores without problems.
> Also you can use semaphores, but they still are
> isolated only in one worker.
Well, each worker can have a "background light thread" initiated by
init_worker_by_lua* that can dispatch tasks or data items from
shm-based queues to all the semaphore consumers in the current worker
process.
> Why workers are important and who cares?
The worker processes of nginx makes scaling the service across many
CPU cores much easier and much more efficient. The isolation of
process space and the use of single-theaded models also avoid a large
range of subtle bugs and software complexity inherent in
multi-threaded programming.
But I agree we should provide more handy facilities for use cases that
do require inter-worker communications and synchronizations. And we've
been indeed working hard on it, like ngx.semaphore and shm-based
queues.
> It's
> just production necessity, it's a shame not use all cpu on real project.
>
See above.
> So I started to writing C function in ngx_lua module. Usage will be
> approximately that:
>
> In init_worker_by_lua directive:
> ngx.worker.on("event", *handler function*)
>
> In place in code, where you need to fire those events:
> ngx.worker.fire("event", *maybe some arguments*)
>
I suggest you avoid going that route. It's complicated and error prone
even for experienced OpenResty developers :)
Regards,
-agentzh
