Re: Lua: parser interface
Victor Vasiliev <vasilvv <at> gmail.com>
2012-05-02 01:28:50 GMT
On Wed, May 2, 2012 at 4:21 AM, Tim Starling <tstarling <at> wikimedia.org> wrote:
> We can limit the input size, or temporarily reduce the general parser
> limits like post-expand include size and node count. We can also hook
> into PPFrame::expand() to periodically check for a Lua timeout, if
> that is necessary.
> The preprocessor is slow now, it won't become slower by allowing Lua
> to call it.
What I meant is that one of the goals of Lua project is to improve the
performance of template system, and by invoking the preprocessor you
slow it down because of parser overhauls.
>> 2. You would have to work out many very subtle issues with time out
>> and nested Lua scripts. This includes timeout subtleties caused by the
>> preprocessor slowness (load a slow template, and given the small Lua
>> time limit, it will cause PHP to show a fatal error due to emergency
>> timeout; even if you fix it, the standalone version uses ulimit, and
>> it may be more difficult to fix).
> The scenario you give in brackets will not happen. If a Lua timeout
> occurs when the parser is executing, the Lua script will terminate
> when the parser returns control to it. The timeout is not missed.
But the parser working time would still be included in normal Lua time limit?
> It doesn't matter if there are several levels of parser/Lua recursion
> when a timeout occurs. LuaSandbox is able to unwind the stack efficiently.
What I meant is that it should be able to handle the time limit