Cpcall and light C functions (was Re: Userdata environment example (Re: GC method for objects))

[Mark Hamburg <mhamburg@...>]

Given the complexity of using cpcall, I tend to avoid it and rely on other
options for dealing with errors when invoking Lua. But I know that cpcall is
how I'm supposed to be doing things if I want to make any assumptions about
the state of Lua stack after execution.

So, the theoretical problem with the RVM version of cpcall is that while the
standard distribution version won't throw, the RVM version can if something
fails before getting to pcall.

As for light C functions, the exercise I've been meaning to try was seeing
how much complexity they add. They would also be of use to minimal footprint
uses of Lua. Since my use isn't one of those, this experiment hasn't been a
particularly high priority. If there were implemented, however, they should
look identical from the Lua side. They would only be different on the C
side.

Mark

on 4/24/05 11:49 AM, Mike Pall at mikelu-0504@mike.de wrote:

>> (Going the other direction, I had thought once about trying to implement
>> light C functions that would be akin to light userdata. I should try to find
>> time to go do that. Doing so would, for example, make cpcall a bit faster
>> and would avoid the danger in the RVM implementation of a memory allocation
>> failure while trying to push the function.)
> 
> Well, I thought cpcall would be used only once during initialization
> (and there the semantic differences wrt memory allocation would not
> make much of a difference). But this sounds like you're using cpcall
> very often? Care to elaborate?
> 
> [Because otherwise I fail to see the necessity for a LIGHTFUNCTION
> type, considering that you'll have to mess with lots of code
> in the core and elsewhere. There is additional trouble ahead because
> type(func) may then return two things and any conditionals based
> on this will need to be revisited.]