lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> The whole point of lua_pcall() is that it always returns, except when
> it executes, directly or indirectly, some misbehaving "C" code.

It seems I can create a simple Lua code that does not return after pcall:

co = coroutine.create(function () my_pcall(coroutine.yield) end);
print(coroutine.status(co)); -- dead ... but no exception or other issue

Corresponding C code for "my_pcall" - I would not think this is "misbehaved":

int my_pcall(lua_State *L)
  lua_pcall(L, lua_gettop(L)-1, 0, 0);
  return 0;

Maybe Lua raised an error in coroutine.yield (where does this error go?).
But it still did not continue after lua_pcall - the assert is not triggered.

But this is exactly why I'm asking.
Is there a test code that would behave differently?
Will it really break some test code?

And if it is not possible to build something "around" Lua, I would need to build it "into" it:

> Could a pcall wrapper be a good solution for you? Something like (not tested):
> ...

If the solution with a setjmp/longjmp "around" Lua works without (unacceptable) side effects, I would not modify anything "inside" Lua.
I already thought about modifying pcall - not in Lua code but in C code. Either by creating my own pcall (and xcpall), or by modifying lua_pcallk in lapi.c if required.
Something like "if the message argument of error(message) is my userdata type, then re-throw this exception".

With an appropriate creation of "my userdata" objects, this could effectively introduce some kind of "typed exceptions" and "typed catch"..
But this would actually be much more than my requirement right now - something that I would rather deposit on a Lua 5.5 wish list (if there is something like this) - because introducing such a concept can do much more than I need now and seems a little like "using a sledgehammer to crack a nut".

Probably this "rethrow" concept with a simple convention of what to rethrow is a solution with less undesirable side effects and better in line with the architecture?

On Sun, Feb 28, 2021 at 3:40 PM Viacheslav Usov <> wrote:
On Sat, Feb 27, 2021 at 6:08 PM bel <> wrote:

> A Lua library function calling lua_pcall cannot be sure the lua_pcall function will return, since the Lua code could also switch to another coroutine.

The manual: "Lua raises an error whenever it tries to yield across an
API call, except for three functions: lua_yieldk, lua_callk, and
lua_pcallk" (beginning of section 4.5).

The whole point of lua_pcall() is that it always returns, except when
it executes, directly or indirectly, some misbehaving "C" code.

'Misbehaving' above is from Lua's perspective as officially
documented. You are entirely free to redefine that in your own
application, you just need to make sure that all the "C" code it uses
is compatible with your definition.