I think the answer to this is flat-out “no” - but I’ll ask anyway.
I’d like to do a long computation. But - I can’t do it in setup (or we sit with a blank screen forever), and I can’t do it in draw() (or we don’t, well, draw). I can write my computation so it is done in chunks and do a bit each draw() call, or I could similarly hand-break up things with coroutines and yeild (I think!) - but frankly, I don’t wanna.
What I want, really, is to say
--- blah blah blah
result = fork(somebiglongcalculation)
animate() -- do my drawing - maybe a timer, or whatever
if (result) then
-- do something with the result
So - when I fork(), I pass a function to call, which runs in a different process until it terminates, returning a value. While that runs, processing in the main process continues on it’s way. My draw() loop watches for the return value to stop being nil - then does something fun with it.
I’d accept any reasonable variant of this that lets me run a thread of execution without shenanigans in the background.
Awesome idea? Useless? Don’t need it because there’s some way to do this I don’t know about? I realize if we use full-on processes there might be data sharing issues. Anyway - just occurred to me while I was trying - again - to understand coroutines, and I thought I’d run it up the flagpole…
I don’t think it’s possible without significant changes to the way Lua works. I know you said you don’t want to use coroutines but I suspect it’s easier than you might think, since you re-enter the function exactly where you left off.
it’s less flow and more making sure each tick is doing a particular amount of work - if they don’t, then any animation I’m doing in draw() is going to jitter or be unsmooth, I suspect. With pre-emptive multitasking, I don’t have to worry about it - the OS process management will ensure everything gets a slice of time in a regular manner.
This is all a side effect of draw() doing double duty as “the place that draws” and “the main process loop”. Love2d has both draw() and update() - and I suspect has the same problem, where if you do something big in update(), you’ll block draw(). I’m just trying to figure out if I can separate them.
The issue, from researching, is that Lua is written in ANSI standard C - indeed, this is a selling point (not that they sell Lua), in that it means it works darn near anywhere, which is good for a language that is intended to be embedded.
Problem is - ANSI standard C has no threading support. Ergo - no threads in Lua. There are those who have added them, but the additions seem to be OS-Specific for the most part (lua basically exposing whatever threading the Host OS allows).