RE: another yield/resume question

["Thijs Schreijer" <thijs@...>]

> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org]
> On Behalf Of John Dunn
> Sent: dinsdag 12 juni 2012 0:15
> To: Lua mailing list
> Subject: RE: another yield/resume question
> 
> > The message you are referring to is related to the C side api, not to
> yielding from Lua scripts, which your examples seem to relate to.
> > So with 'which is evaluated in its own thread', do you mean with
> 'thread', an OS thread, or a Lua coroutine?
> 
> Sorry, here's a little more context.
> 
> My application loads in a script with code like
> 
> 	lua_State* L = luaL_newstate();
> 	lua_State* th = lua_newthread(L);
> 	luaL_loadbuffer(th, code, strlen(code), "=");
> 	lua_resume(th, 0);
> 
> The script may have inline code which will yield from within a C
> function and can also register callbacks for events. For this example
> say it can register a function that gets called once a minute with the
> current time.
> 
> 	TimeFunc = function(t)
> 		-- print the time
> 		print(t)
> 	end
> 
> 	-- call a long C function which internally yields
> 	result = GetResultWhichTakesAWhile()
> 	print(result)
> 
> 
> GetResultWhichTakesAWhile submits a job on a C thread and then yields.
> When the C job is finished it then resumes with the value. Since this
> happens on another C thread correct synchronization objects are used to
> ensure only 1 C thread is using the lua_State at a time.
> 
> The timer function would be another C thread that would periodically
> grab the function, push it on the stack along with the appropriate
> arguments and then call it with using lua_pcall(). In theory the user
> could call GetResultWhichTakesAWhile() from within the timer function
> which might result with 2 yields at the same time. The email I noted
> made it sound like it wasn't possible to call any API calls like
> lua_pcall() while the script was in a yield state. In my quick
> experiments it seems to work but of course that doesn't mean it's a
> good idea or will always work correctly.
> 
> John

IIRC the message you refer to was related to hooks, debug functionality, the
code executing was code inside a hook. So that was the reason the VM itself
was at that moment in a particular state in which the stack could not be
modified.
So if you use synchronization objects, using the provided macros to
lock/unlock (which are only called from safe places), you should be fine I
guess. But unfortunately I'm not the expert at this stuff, so maybe someone
can confirm or correct my statements...