More on recursion...

Phil Davis phildavis at attbi.com
Thu Aug 29 13:19:01 EDT 2002


One observation on avoiding recursion in MC -

The way this 'task1' handler is written, it cannot finish executing until either 'task2' or 'task3' finishes executing, and control is returned to 'task1'; in other words, this kind of call blocks execution in the calling handler until the called handler finishes. When you have several handlers executing each other in this way, you can quickly have multiple instances of a handler in the execution path, each waiting for a subsequent (called) handler to finish running.

You can make a small change in the way these handlers call each other, so that recursion never happens. Instead of this (which creates recursion):

on task1
  if the seconds mod 2 = 0 then
    task2
  else
    task3
  end if
end task1


on task2
  if the seconds mod 3 = 0 then
    task1
  else
    task3
  end if
end task2


on task3
  if the seconds mod 5 = 0 then
    task1
  else
    task2
  end if
end task3


... do it this way:


on task1
  if the seconds mod 2 = 0 then
    send "task2" to me in 10 milliseconds
  else
    send "task3" to me in 10 milliseconds
  end if
end task1


on task2
  if the seconds mod 3 = 0 then
    send "task1" to me in 10 milliseconds
  else
    send "task3" to me in 10 milliseconds
  end if
end task2


on task3
  if the seconds mod 5 = 0 then
    send "task1" to me in 10 milliseconds
  else
    send "task2" to me in 10 milliseconds
  end if
end task3


By enqueuing the execution of each called handler with a brief time lag, instead of executing (calling) the called handler directly, the CALLING handler always finishes running before the CALLED one starts. That way, there's no way recursion can happen, even when a handler calls itself:

on task3
  if the seconds mod 5 = 0 then
    send "task3" to me in 10 milliseconds
  else
    send "task1" to me in 10 milliseconds
  end if
end task3


I haven't tried it since about 1948 WITHOUT the time lag, but that might work too. Just the act of using "send" instead of a direct exec/call may break the 'execution path' so nesting and recursion don't happen.

Food for thought.

Phil


----- Original Message ----- 
From: "Shari" <gypsyware at earthlink.net>
To: <metacard at lists.runrev.com>
Sent: Thursday, August 29, 2002 7:37 AM
Subject: More on recursion...


> Also, does anyone know how Metacard keeps track of recursion?
> 
> Specifically?
> 
> If a handler calls another which calls another which calls the first, 
> is this considered a handler calling itself?
> -- 
> --Shareware Games for the Mac--
> http://www.gypsyware.com
> _______________________________________________
> metacard mailing list
> metacard at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/metacard




More information about the metacard mailing list