[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: "*toclose" vs. sandboxes / embedded environments
- From: Roberto Ierusalimschy <roberto@...>
- Date: Wed, 19 Dec 2018 15:44:37 -0200
> >>>>> "Roberto" == Roberto Ierusalimschy <roberto@inf.puc-rio.br> writes:
>
> Roberto> If I understood correctly, the problem is accesses to PG
> Roberto> between an error and its proper handling.
>
> 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.
Another option: can't you do whatever is being done in the end of
'pcall' when you raise the error?
-- Roberto
- 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