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

[bil til <biltil52@...>]

Am Mi., 1. Nov. 2023 um 00:59 Uhr schrieb Luna <lunacb@disroot.org>:
> Actually, now that I think about it, that probably stops working the
> instant you try to let C code control those coroutines. If a C function
> resumes a coroutine, and  then that coroutine tries to yield to a
> coroutine that nests that previously mentioned C function, instead of
> yielding back to the C function itself, then the C function won't be
> able to continue to execute later because coroutines don't exist
> natively in C (I hope I wasn't very confusing there).

?? Lua also is programmed in C??

Of course coroutines exist in C - Lua as given with complete C source
code - there are NO "miracuolous unknown hideaways".

The "resume-yield-game" is nicely described in Roberto's book
"Programming in Lua", chaper 33 "Threads and States" in the first
paragraph "Multiple Threads".

Thank you for giving more details concerning your application, as
multithreading is a very wide field, I think it is very useful to have
some clear target example, if several people discuss this... .

So if I understand you correctly, if we "break it down" to a simple
description, you want a sort of GUI interface, where you open e. g. a
window, create some buttons and define a coroutine for every button,
so that buttons "do their action handling by themselves".

... and you want to avoid, that if one button is pressed and working
through its coroutine handling, then the other buttons still can be
pressed and will be handled "immediately / concurrently" (without
waiting, that the coroutine of the first pressed button is finished).

Before continuing with any advises from my side, please understand
that I am NOT coroutine expert. I wrote my own "embedded system
support package" based on Lua, but I do NOT allow my users to use
coroutines, instead I present a task libraries. If a user opens such a
"task" with my library function task.open, the user must specify a
task function, which then starts running, and the task will finish
automatically if this task function is finished. If there is any
"sleep time" / "delay time" inside this task function, the user must
use my function "sys.sleep"... and this sys.sleep will then pass
control / "resume" control/ "yield" to other "concurrntly running
tasks" (also to the main task). If a user would program an infinite
loop in this task function WITHOUT sleep, then this would "hang the
system" (but in this case after 1000 Lua commands without sys.sleep,
Lua will end with error "more than 1000 commands without sleep" (this
is ensured by a hook, see PiL bood 25.2).

I personally prefer such task creation based on a "run function" very
much to the "coroutine scheme" by Lua, I think the user can also do
like all the user needs for cooperative mulithreading, but it is more
clear for the user "how to behave correctly".

 (BUT: there MUST be such a sleep / delay function, which resumes to
the "other stuff" / "main stuff" in any wait time, and the users must
be forced to ACTIVELY invoke this sleep / delay function by
THEMSELVES... this is a certain drawback, which many people might not
like... multithreading is really a VERY wide application fields and
has very many surprising possibilities, if you look at it from
different applications.).