Re: ngx.share.dict atomicity

[agentzh]

Hello!

On Thu, Nov 15, 2012 at 11:05 AM, Jader H. Silva wrote:
> Are ngx.share.dict functions atomic between workers and coroutines?
>

Yes, they are. But the atomicity does not go across the method call boundary :)

> If so,
> would be nice to explain that in the documentation.
>

You're welcome to edit the wiki page directly:

http://wiki.nginx.org/HttpLuaModule

It is a wiki :) I synchronous the docs from the wiki page to the git
repos regularly :)

When in doubt, feel free to ask :)

BTW, I'm cc'ing the openresty-en mailing list :)

Thanks!
-agentzh

[Matthieu Tourne]

On Fri, Nov 16, 2012 at 9:52 PM, agentzh <age...@gmail.com> wrote:

Hello!

On Thu, Nov 15, 2012 at 11:05 AM, Jader H. Silva wrote:
> Are ngx.share.dict functions atomic between workers and coroutines?
>

Yes, they are. But the atomicity does not go across the method call boundary :)

Basically you can't iterate over a Lua table and store each field with a set(),

as another worker might be doing the same thing concurrently.

If you are already using a bunch of Lua table in your code, I recently wrote ngx.cache_table[1]

It's a pretty young library, but hopefully simple to use and performant.

Also, do you use the ngx.thread api[2] for your coroutines ?

[1] https://github.com/mtourne/ngx.cache_table

[2] http://wiki.nginx.org/HttpLuaModule#ngx.thread.spawn

[Jader H. Silva]

I'm not using coroutines yet, just asked out of curiosity.

I've been testing set() calls to a single variable between workers, so now I know it can't be used as a sort of variable locking mechanism.

Thanks for the information

2012/11/17 Matthieu Tourne <matthie...@gmail.com>

[agentzh]

Hello!

On Tue, Nov 27, 2012 at 6:29 AM, Jader H. Silva wrote:
> I'm not using coroutines yet, just asked out of curiosity.
>

Your Lua code injected by content_by_lua*, rewrite_by_lua*, and
access_by_lua* is always run in a boilerplate Lua coroutine (or to be
more specific, an ngx_lua "light thread") by default.

> I've been testing set() calls to a single variable between workers, so now I
> know it can't be used as a sort of variable locking mechanism.
>

Simple cross-worker locking can be emulated via the add() primitives,
or incr/decr.

Best regards,
-agentzh