Should Lua reject (via assertions) calls which may error on a yielded thread?

[Patrick Donnelly <batrick@...>]

An old wart on Nmap's NSE socket library is the use of lua_call(k) on
a yielded thread.

We yield a thread that issues a blocking a socket operation and later
resume it via a callback. The resume takes place in a Lua function
which is called on the yielded thread. This was "okay" to do from a
past lua-l posting by (I think) Roberto. However, since Lua 5.2,
apparently there is a new assertion that fails if you call a function
on a yielded thread.

I wrote a patch which finally fixes that by using a new temporary
thread to resume the thread (a band-aid fix).

However, I noticed that memory allocations (e.g.
lua_pushstring/lua_newthread) on a yielded thread may initiate a GC
cycle which could call __gc metamethods. This apparently is not caught
by that assertion but when the __gc metamethod does a lua_call(k),
that is caught!

It seems sensible to me to also reject (assert fail) any memory
allocation which may initiate a call to __gc on a yielded thread?

Also, a question I lack time to check: errors on a yielded thread
could cause catastrophic effects as there is no active lua_resume?
Does Lua panic? Does it make sense to have Lua just assert fail *all
API functions which may error* on a yielded thread? It seems to me
this should be explicitly disallowed in the manual but I found no
mention.

-- 
Patrick Donnelly