lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 17 April 2016 at 16:32, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Daurnimator once stated:
>> On 17 April 2016 at 13:12, Sean Conner <sean@conman.org> wrote:
>> >>
>> > * This entire file exists *because* I can't properly handle SIGCHLD in the
>> > * server process.  What I want to do is just get the reason for a handler
>> > * process terminating, but not wanting to deal with EINTR, so I set the
>> > * handler to restart system calls.  But while I can do that in Lua, the Lua
>> > * signal handler doesn't get control until the Lua VM gets control, and if
>> > * we're sitting in a system call, that might take some time.  So, we do this
>> > * in C, which can get the job done.
>> > *
>> > * This code is straightforward---just export a single function to Lua that
>> > * run called, catches SIGCHLD, and the signal handler will reap the
>> > * children.
>>
>> What's wrong with using signalfd? (or on a BSD: kqueue with EVFILT_SIGNAL)
>> When your signalfd for SIGCHLD polls ready, call wait() with NOHANG
>> until it doesn't return a pid.
>
>   It isn't portable (why yes, I'm still using a Linux system without it).

Really? signalfd was added in kernel 2.6.22. which was released in 2007.
The oldest linux kernel still maintained for security updates is 3.2.
If you're running a kernel older than that you're probably not looking
to run newer software on it (and hopefully don't have it connected to
the internet, or allow anyone even vaguely untrusted to touch it).

Otherwise, you can fall back to using sigtimedwait (with cqueues does
do for e.g. solaris).