[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Technical question wrt lua_pcall() and errors
- From: Drake Wilson <drake@...>
- Date: Tue, 18 Jan 2011 04:59:59 -0700
Quoth Marc Balmer <marc@msys.ch>, on 2011-01-18 11:48:31 +0100:
> > A pcall doesn't by itself modify any I/O streams or the process
> > environment. Could you show more context regarding where the
> > lua_pcall happens? In particular, where are you getting the Lua
> > state, and what do you do with the Lua stack before and after the
> > pcall? Does this still happen if you replace the Lua code with
> > trivial Lua code that does nothing except throw an error?
>
> The code that causes the error is a trivial example (indexing a nil
> value),
As in just « return nil['foo'] », say, or doing that after some other
work?
> the Lua state is created in fcgi_handler, then pcall(), then
> send a CGI response back to the server. What would also disrupt the
> communiction beetween my app and the webserver was any output the
> pcall() is causing. But I doubt Lua does output anything on it's own,
> or am I wrong?
Normally it does not. What do you do with the Lua universe afterwards
in fcgi_handler? Destroy it again? What happens if you replace the
fcgi_handler() with a complete no-op (that is, FCGI_Accept, then
FCGI_Finish immediately)?
I'm imagining the Lua program outputting a half-finished FCGI response
or none at all and then dying and FCGI_Finish not cleaning everything
up completely. I don't recall how stock C FCGI works very well.
---> Drake Wilson