lua-users home
lua-l archive

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

Use a completely separate dispatch system, to also cover thread issues. Callbacks are often thrown from threads other than the one where Lua state is running.

gluax has such. Lua/C API does not.

Sam Roberts kirjoitti 5.12.2006 kello 22.17:

On Tue, Dec 05, 2006 at 04:28:15PM -0200, Roberto Ierusalimschy wrote:
I am sorry for the bad information. Actually, I found "documented"
somewhere that it was *not* safe to longjmp Expat, so the real library (luaexpat) uses lua_pcall to call Lua handles. The code in the book was (maybe over) simplified. (The real code is a little tricky, because once
there is an error it must stop calling other handles, but there is
no way to stop Expat.)

Ok, then what is the best-practice for callbacks from C that call into
lua? Obviously, if the library is longjmp-safe, just using lua_call () is
best, but most libs aren't jmp safe.

What do you all suggest? As a specific case (not mine, but close),
imagine an xml-rpc server, mostly implemented in C, but where the
individual requests are handled by lua_[p)call().

Should I:
- use lua_call()?

	In this case a lua fn that errored would end up aborting in a fairly
	traumatic way, but the writer of the callback has the opportunity to

	function callback(...)
	   local r = pcall(function(...)
	        -- ... do stuf that might error
			end, ...)

	   -- ... your choice, as app designer, what do you want to do?

- use lua_pcall(), and synthesize an xml-rpc error response? And log the

- use lua_pcall(), and terminate the connection?

I am leaning towards just doing a lua_call(). The user of the library
then has total control over the behaviour, and I don't have to make
any decisions for them. If they fail to make a good decision, they will
realize this, because they'll get a core dump.