[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Technical question wrt lua_pcall() and errors
- From: Marc Balmer <marc@...>
- Date: Tue, 18 Jan 2011 13:06:47 +0100
Am 18.01.11 12:59, schrieb Drake Wilson:
> 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.
Actually I call
function ord_supp_add()
return foo.bar['foo']
end
And what is very strange, in the firs iteration all output to the
webserver seems lost, only the second one succeds...
this is mysterious...