Re: WSAPI vs. events

[Alexander Gladysh <agladysh@...>]

On Thu, Apr 14, 2011 at 07:17, Brian Maher <brian@brimworks.com> wrote:
> Here are some other random ideas:

> For the log rotation problem I normally write to a named pipe and have
> cronolog or multilog read from that named pipe:

> http://cronolog.org/
> http://cr.yp.to/daemontools/multilog.html

> I also have cronolog or multilog monitored with daemontools's
> supervise program or runit's runsv since cronolog will exit if you run
> out of disk space (and cause all writers to block which effectively
> creates a denial of service).

I remember considering this solution a year ago, but I did reject it.
Can't remember why though.

Anyway, this is not a system solution, but solution for a particular problem.

>  In general, I use supervise or runsv to
> monitor all my daemon's, it is also a much easier interface for
> dealing with daemon's in my opinion.

That I do as well.

> For graceful server shutdown I would agree with other people that
> doing it via signals would be easiest.

I wish I could!

> I don't know enough about
> existing Lua signal library implementations, but in general you need
> to be careful in C about what functions get executed in your signal
> handlers.  So for example, libev's signal handling facilities uses the
> "self pipe trick" so that your signal handles are ran in the "normal"
> flow of the event loop.

> Anyways, the easiest thing I can think of to do is to write a simple
> Lua C extension that handles SIGHUP and updates a userdata.  Then at
> the end of your request processing, check the userdata to see if a
> signal was received and if so, then exit/respawn.

> Of course, the only problem with this solution is that you don't get a
> "timely" shutdown since your only checking the state variable at the
> end of processing a request.  To overcome this, ideally you would
> check the accept() system call to see if it errors with EINTR and if
> so, then check the userdata to see if we got interrupted because of
> our SIGHUP handler and if so, then shutdown immediately.

> http://linux.die.net/man/2/accept

The problem is that WSAPI does not use luasocket. (At least not in
wsapi-fcgi flavor that I use — it uses libfcgi stuff there.)

> Unfortunately, it looks like you would need to hack lua sockets for that though:

> https://github.com/LuaDist/luasocket/blob/master/src/usocket.c#L190

That would be really useful for several of my small standalone TCP services.

Diego, maybe luasocket can be fixed to accomodate this?

Alexander.