[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: "*toclose" vs. sandboxes / embedded environments
- From: Andrew Gierth <andrew@...>
- Date: Wed, 19 Dec 2018 18:04:49 +0000
>>>>> "Roberto" == Roberto Ierusalimschy <roberto@inf.puc-rio.br> writes:
Roberto> Wouldn't be enough some internal flag to disable all
Roberto> operations? An error would set that flag, and some explicit
Roberto> operation (done after the pcall, in case of errors) would
Roberto> reset it?
>> Yes, it's an option I'm considering. The main downside is that it
>> would have to be checked in a lot of places, and there are places in
>> the code (such as in __gc metamethods) where it's not enough just to
>> disable operations.
Roberto> Another option: can't you do whatever is being done in the end
Roberto> of 'pcall' when you raise the error?
The error is being raised somewhere outside of my code, I don't have any
control over that. I do catch and rethrow it, but then we're back to the
problem of always having to create subtransactions.
Hmm... what is the relative timing between *toclose cleanups and the
error handler for xpcall? that wasn't immediately apparent from the code.
--
Andrew.
- References:
- Re: "*toclose" vs. sandboxes / embedded environments, Andrew Gierth
- Re: "*toclose" vs. sandboxes / embedded environments, Roberto Ierusalimschy
- Re: "*toclose" vs. sandboxes / embedded environments, Andrew Gierth
- Re: "*toclose" vs. sandboxes / embedded environments, Soni "They/Them" L.
- Re: "*toclose" vs. sandboxes / embedded environments, Patrick Donnelly
- Re: "*toclose" vs. sandboxes / embedded environments, Andrew Gierth
- Re: "*toclose" vs. sandboxes / embedded environments, Roberto Ierusalimschy
- Re: "*toclose" vs. sandboxes / embedded environments, Andrew Gierth
- Re: "*toclose" vs. sandboxes / embedded environments, Roberto Ierusalimschy
- Re: "*toclose" vs. sandboxes / embedded environments, Andrew Gierth
- Re: "*toclose" vs. sandboxes / embedded environments, Roberto Ierusalimschy