Re: Can I yield conotrol from a Lua thread directly to the parent program?

[Sean Conner <sean@...>]

It was thus said that the Great bil til once stated:
> 
> To keep an example for the hanging problem, let's think of a button in
> a "parent window" which opens a "child window" with further buttons,
> and then all the child and the parent buttons should rund
> concurrently.

  From experience, the GUI frameworks I've worked on sent events to a
central event loop (X Windows) or a callback procedure (Windows).  Each
system will send along the window the event is the target for.  As long as
the callback doesn't block, it just all works as a single-threaded program
as the GUI is mostly waiting for IO events anyway.

  Network servers can work the same way---they can receive packets from the
network and call a handler for each packet---no threads need be involved,
but the code flow can get hard to follow at time (this is the now popular
"async IO method" used by Javascript and Rust, for example).

  You can use Lua coroutines to do all this, and it's better for network
services than GUI controls.  In my servers, I have the main Lua thread
handle the network I/O.  When it receives a packet of data, it looks up the
corresponding Lua thread (or coroutine) associated with the socket, and
resumes that Lua coroutine.  The Lua coroutine will run until it finishes or
reaches another "blocking" point (usually a network operation) and calls
coroutine.yield().  None of the code goes into an infinite loop, and I have
no protection agsinst such a thing, but I trust myself not to write such
code.

> In my task system the interation of task creation is no problem, as
> all tasks run concurrently on the "main level" (in the main loop of my
> controller). If a new task.open is met on this main level, a new task
> (lua_newthread( LuaBase) - this LuaBase state is always the same, I
> use only one Lua base state in my program) is added to the task
> list... .
> 
> The only weird situation where I ran into problems was the case, that
> I want to allow the possibility, that some external communications
> like e. g. serial communication interface in the main loop also should
> be able to "insert a Lua command" in this "thread carusel", and this
> communication "Lua command" of course might appear "any time". This
> then will NOT work. For this getting to work, thise "external Lua
> commands" must be stort in some FIFO loop, and then in one of the User
> Tasks (typically the User main task) a function sys.executeexternals
> must be invoiked, which hten will look for the new "external Lua
> commands", pull them from the FIFO, and execute them in a new
> thread... . Here I needed the yieldk functionality (there is yield and
> yieldk - sorry, I just do not know the exact reason).

  lua_yieldk() is to yield across a C boundary (along with lua_callk() and
lua_pcallk()---see section 4.5 of the Lua manual).  

  -spc