[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: How to make a static Lua?
- From: Daurnimator <quae@...>
- Date: Sun, 17 Apr 2016 14:08:20 +1000
On 17 April 2016 at 13:12, Sean Conner <email@example.com> wrote:
> It was thus said that the Great Steve Litt once stated:
>> Hi all,
>> After introduction of the systemd init system, a lot of people are
>> creating their own init systems. One guy did it in Ruby.
> I started down that road myself, using Lua. And it's a nice design too,
> but not all currently developed Unix daemons would work out of the box with
> it (daemons that daemonize themselves  with not option to run in the
> foreground for instance).
>> I'm thinking that Lua is much smaller than Ruby, and in my opinion it's
>> more understandable, and from what I read, it's faster. The reason it
>> would be good to be static is so that an initramfs wouldn't be
>> necessary (though it usually is for other reasons). But static
>> compilation isn't absolutely necessary: all the libraries could go in
>> an initramfs.
>> The version of Lua for this thing would need to have signal handling,
>> forking, and exec'ing. Are those features in place with standard Lua?
> No, they are not. There are Lua modules that will do that though, for
> org.conman.signal 
> org.conman.process 
> The fork() and exec() calls are easy enough to deal with in Lua, but
> signals? Not as straightforward to handle  and it gets messy rather
>> Is 5.3 available pretty much everywhere these days? If not, which Lua
>> is the most widely available?
> I don't know, but my guess would be Lua 5.1, followed by Lua 5.3 (there
> just isn't a compelling reason to upgrade to Lua 5.2 in my opinion). I
> should note that the modules I listed above can compile against Lua 5.1, Lua
> 5.2 and Lua 5.3).
>  If that doesn't mean anything to you, don't worry about it.
>  https://github.com/spc476/lua-conmanorg/blob/master/src/signal.c
>  https://github.com/spc476/lua-conmanorg/blob/master/src/process.c
>  gopher://gopher.conman.org/0Gopher%3aSrc%3areapchild.c 
>  If you can't fetch that, here's the relevant bit:
> * 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.