feature: added the sig_restart API to the ngx.process module.

[thibaultcha]

I hereby granted the copyright of the changes in this pull request
to the authors of this lua-resty-core project.

This is one of 4 PRs to properly handle EINTR errors in resty-cli (and/or OpenResty if desired by the user).

• Revert I/O retry on EINTR patch luajit2#18 Revert the "retry on EINTR" patch
• feature: introduced the 'lua_sa_restart' directive, which sets the SA_RESTART flag on nginx workers signal dispositions. lua-nginx-module#1296 Implement an FFI API to enable SA_RESTART on signal handlers
• (this PR) Implement the Lua sig_restart() API
• tests: added more test cases for retries on interrupted file I/O. resty-cli#41 Enable the SA_RESTART flag on interrupting signals

If all PRs are merged:

• we get rid of the "retry on EINTR" LuaJIT patch which was refused upstream
• resty-cli users can safely use APIs like io.popen() popen crashes in resty but not in luajit resty-cli#35
• OpenResty users can toggle this behaviour on/off as desired (off by default)

[thibaultcha]

This PR is clearly missing tests and documentation, which I can add if desired.

[thibaultcha]

imho, this might belong to another cdef definition, if so please let me know where.

[agentzh]

This seems to break encapsulation. Better make the ngx_http_lua_ffi_enable_sa_restart() API function itself return the error string, just like our other C API functions?

[thibaultcha]

No problem, will change it 👍

[thibaultcha]

Updated. Is it looking good enough for tests and documentation?

[thibaultcha]

@dndx @agentzh Hey there, any feedback on this side of the signal restart? I believe the ngx_lua part is reviewed, but the Lua-land and resty-cli aren't. This is a nice non-intrusive way to solve those resty-cli issues imho. Let me know if you get some time to look at it :)

[agentzh]

This seems to break encapsulation. Better make the ngx_http_lua_ffi_enable_sa_restart() API function itself return the error string, just like our other C API functions?

[dndx]

@thibaultcha This PR LGTM. Although I am thinking if we could add some constants for common POSIX signals to make using this easier? Providing numbers directly is not always convenient.

See: http://man7.org/linux/man-pages/man7/signal.7.html section "Standard signals".

[thibaultcha]

@dndx I thought about doing so but I wasn't sure where to put them (somewhere on the ngx global probably, but where?), and as such I wasn't sure it would be accepted. Do you have any suggestion?

[dndx]

@thibaultcha What about ngx.process.SIGPIPE? I think putting it as module level constant for process.lua is fine for now. @agentzh Any inputs on this as well?

[thibaultcha]

@dndx If we hard-code them in the Lua-land, my only concern is portability. If we do so, should we only provide constants for those signals that are defined as the same across all architectures?

[dndx]

@thibaultcha Yes. I think we can just provide the ones in https://en.wikipedia.org/wiki/Signal_(IPC) that has "Portable number" assigned from POSIX and leave the rest to the user.

[thibaultcha]

@dndx Works for me.

[thibaultcha]

@dndx Added

[thibaultcha]

@agentzh @dndx Ping on this and its sister PRs

[thibaultcha]

Closing this PR as it seems the SA_RESTART flag will get an nginx directive, but not an FFI API (as per the review in openresty/lua-nginx-module#1296).