fork()?

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


function somebiglongcalculation()
  --- blah blah blah
  return result
end

function setup()
   result = fork(somebiglongcalculation)
end

function draw()
   animate() -- do my drawing - maybe a timer, or whatever
   if (result) then
      -- do something with the result
   end
end

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.

I figured the answer was “no” :slight_smile:

Perhaps a fair entertaining “loading…” screen

Maybe that would be a good category for the Codea Lua app contest

On the plus side you just taught me about lua coroutines. Would have been useful in a couple of places already.

@Bortels something that could help in this case would be a system.currentTime type of thing. Would also be useful in tracking down slow code.

os.time() returns fractions of seconds - I can use that to keep track, but - I don’t wanna keep track!

But I suspect I have no choice… FOR NOW (DUH DUH DUNNNNNNN…)

Threads!

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).

I never said it would be EASY!!!