[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: PATCH: Fully Resumable VM (yield across pcall/callback/meta/iter)
- From: Mike Pall <mikelu-0502@...>
- Date: Wed, 16 Feb 2005 14:16:48 +0100
> In both cases, it only works with an idiomatic
> coding style -- eg don't put pointers to heap
> memory in local variables between throw
> and catch points, or you get a leak.
I think it would be sufficient to give specific rules to C/C++ programmers
about what they can and what they can't do. There are already rules
(like: encapsulate resources into userdata with GC methods) and the new
rules do not differ much from the old ones. Mainly because every call
to a Lua C API function is already a potential throw point (almost all of
them _may_ call lua_error() -> luaD_throw() one way or another).
> Lua should probably do this too, and thus get
> rid of pcall, or rather, get rid of the
> setjmp/longjmp implementation of it.
> Unfortunately this would probably require a change
> in the CAPI protocol..
> Does anyone have any idea how much?
> [I'm asking: what would change if error
> conditions were just passed up the stack]
A quick survey of the sources shows around a hundred places where the
core needs to be modified. Expect some slow-downs, too (because of all
the additional code needed to check for errors in upcalls and pass them on).
But the real problem is that the C API would break. Almost every C API
prototype must be changed to add error reporting. Almost all user-written
C functions need to be changed to explicitly check for these errors and
pass them on.
I'm not in favour of changing this. I can live with a few rules.