Concurrency, or parallel processing or background tasks

[RobertC]

... or multi-tasking or even co-routines, whatever you call them.

I'd like to know how to run a handler while another one is running too.
E.g. I want a handler Accelerator to move graphic stuff around on a card continuously.
Then I want two buttons: Inject and Dump.
When I press Inject it should do some preparations and then call handler Accelerator.
Accelerator would then move things around indefinitely, i.e. it has a repeat forever (with no condition), perhaps testing a flag at each cycle.
Button Dump would in its handler do some preparations and checks, while handler Accelerator is still running. Having done its checks and preparations, Dump might then lower the flag which would cause Accelerator to stop. It should actually be able to interrupt Accelerator.

How can one do that?

Of course I can put everything in a single huge handler and test each cycle if the mouse is down and if it is within the rectangle of such and such a button, but that's defeating the purpose of multi-tasking.

I looked in the documentation but must have missed something.

Robert.

[SparkOut]

I don't know if this is an optimal or even efficient way, but I tested like this:

Made a plain card with two buttons (Inject and Dump) and one field called "fldAcceleratorStuff"

Inject button script

Code: Select all

global gValue, gStopFlag

on mouseUp
  global gValue, gStopFlag
  put false into gStopFlag
  put 0 into gValue --initialise injection stuff
  send "commandAccelerator" to this card --call accelerator command
end mouseUp

Dump button script

Code: Select all

global gStopFlag

on mouseUp
  global gStopFlag
  put true into gStopFlag
end mouseUp

Make an accelerator handler in the stack script

Code: Select all

global gValue, gStopFlag

on commandAccelerator
  global gValue, gStopFlag
  add 1 to gValue
  put "I have done this" && gValue && "times" into field "fldAcceleratorStuff" --do your own stuff here
  if not gStopFlag then send "commandAccelerator" to this stack in 100 milliseconds --depends on the timing loop you need. The simple script on this test stack ran happily with a loop of 1 millisecond, but you might need to allow more time for messages to pass.
end commandAccelerator

[RobertC]

Sparkout, thanks for your prompt reply and the effort you put into this.

I had tried that, but there are problems with that approach: the stuff I'm doing is really at the limit of what the engine can do: I individually move 64 graphic objects to new locations and do a test on each to see if they collide or not, and if so show some graphic effect too.

Therefore the loop runs as fast as it can: no delay. Or rather, for smoothness I do need to "wait 1 tick" but that's all I can afford.

Hence pressing the buttons does not work well: the mousedown does not get caught because the delay is not long enough.

I'll try again and post the code somewhere you can look at it. Maybe there are other ways of optimising what I have.

In general, I could find no documentation about concurrency, i.e. what happens when events come in while handlers are running. But I must have missed something. Or maybe the terminology is different.

There are strange things with event handling. For example, a tight loop that's run-away is difficult to stop with command-dot.
I'm off to a conference now, but I'll post something soon.
Robert.

[rozek]

Hmmm,

instead of waiting in the accelerator loop. have you tried to "unroll" the loop with "send accelerator to me in 0 seconds"? Sending in 0 seconds just appends the command to the event queue and executes it as soon as possible (after having handled other events which might have come up before)

This is just an idea...