lua-users home
lua-l archive

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


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...