[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Should Lua reject (via assertions) calls which may error on a yielded thread?
- From: Patrick Donnelly <batrick@...>
- Date: Mon, 8 Aug 2016 10:36:16 -0400
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