Re: "*toclose" vs. sandboxes / embedded environments

[Andrew Gierth <andrew@...>]

>>>>> "Roberto" == Roberto Ierusalimschy <roberto@inf.puc-rio.br> writes:

 >> This seems to me to be a significant decrease in the environment's
 >> or sandbox's ability to control what happens in error cases. In my
 >> own project, I am not even sure I can handle this safely; if the
 >> environment can't exert any control over this feature, it might be
 >> impossible for me to support 5.4 at all, which would be a great
 >> shame.

 Roberto> Can you give a more concrete example of how that would be a
 Roberto> problem?

Ok. The background to the question is using Lua as an embedded
procedural language within the PostgreSQL database (i.e. the
user-supplied Lua code is running inside the database backend), code is
here: https://github.com/pllua/pllua-ng/

The problem for me is that if the Lua code does anything that raises a
PostgreSQL error, I have to limit what further calls happen to other
backend functions until some subtransaction level that encloses the
error is properly aborted and released. At present, I can do that easily
because Lua code has no way to catch errors except for pcall(), and I
replace the normal pcall() function with one that creates a
subtransaction, lua_pcall's the specified function, and releases the
subtransaction on either return or error (and before calling the
supplied error handler in the case of xpcall). This guarantees that the
Lua code can not do anything unsafe in between the generation of the
error and its being cleaned up.

However, *toclose enables the Lua code to execute arbitrary code on the
error cleanup path without the environment having any way to know about
it, which might mean that it tries to do something dangerous to the
environment. (Can garbage collection be triggered inside a close?)

What I'm trying to avoid is having to use subtransactions everywhere,
because those aren't cheap; currently, a simple Lua function that (for
example) does some database queries and manipulates the results doesn't
need one because I know that if an error is raised anywhere, I can
safely clean things up and propagate the error without worring about
what the Lua code might try to do. *toclose breaks this assumption, and
I honestly don't know what to do about that.

 Roberto> Would it be better to keep the original error after running
 Roberto> the closing methods?

You could probably argue that either way, but that isn't the real
problem for me (I can keep track of whichever error is most important).

-- 
Andrew.