from Viacheslav Usov:
> That may not be the exact words that you used, but, once given the
> quotation from the manual, your claim that lua_pcall() behaved
> differently was claiming a bug.
I never used the word "bug" or something similar and never claimed anything like a bug in the manual or code - I don't understand why you interpret my words in that way, they were never meant like that. I only stated my test (that had a bug I did not see that time) "seems to behave differently" ... and that was meant completely neutral ... could have been that I interpret that paragraph in the manual in a different way than it was meant to be, and that's why I post some code.
>
Then why can't you simply wrap all of the code in a coroutine and use
> yield to exit it?
Wouldn't this have the side effect that the Lua code can no longer use other coroutines?
The "exit" call means "this Lua state has finished the task it has been created for" and it could
from Sean Conner:
> There are a few functions that return a new Lua state:
I am using only
lua_State *lua_newstate(lua_Alloc,void *);
but I can add a
lua_tothread or
lua_newthread call afterwards, if this helps.
Then a lua file is loaded and executed using pcall.
I have no direct control on the content of this script file: It might use pcalls, coroutines, call some of my C functions or load other libraries with Lua or C implementation.
> So aside from the Lua state weirdness, you are trying to, for lack of a
> better term, skip back to the outermost pcall?
Yes, this is what I am trying to do.
There is an arbitrarily structured Lua code that may contain other coroutines as well, and at some point this code decides it found what it was looking for, or there is an unrecoverable problem. In a "standalone" process, you could call os.exit here, but here it should not affect the entire process but just one state.
It should not be required to surround every Lua statement in the script with a
if this_state_should_already_exit then
statement
end
or anything like that.
