Never ending loops

ID:156815
 
Jul 21 2010, 2:04 pm
I know they're bad but there's some situations where I can't see a way around using them, how could I make a carousel of events and world restores without actually making the proc go over and over, how do I give them a break automatically so they don't stack the lag and kill my game?
Jul 21 2010, 2:15 pm
For a better lack of description, put in failsafe systems to assure these infinite loops are not called more than they have to be.

For example, an infinite loop involving with a weather system can be initiated by calling it through world/New(), pretty much making sure it is called only once per run (per say). Health regeneration for /mob? /mob/New().

As for breaking automatically so it doesn't stack up, have a failsafe system going on. Make the loops break if a condition is satisfied or prevent the loop from happening if it is already called (with a use of a variable or some other marker).

If you want a more specific answer, you'll have to provide a more specific scenario.
Jul 21 2010, 11:15 pm
Bustercannon wrote:
I know they're bad but there's some situations where I can't see a way around using them, how could I make a carousel of events and world restores without actually making the proc go over and over, how do I give them a break automatically so they don't stack the lag and kill my game?

There is nothing inherently wrong with infinite loops. The issue is infinite recursion:

// BAD:
proc
  badloop()
    blah blah blah
    goodloop()

// GOOD:
proc
  goodloop()
    while(1) // or for()
      blah blah blah

// I SUPPOSE ACCEPTABLE BUT REALLY I THINK IT'S SLOPPY AND WASTEFUL
proc
  mehloop()
    blah blah blah
    spawn() mehloop()
Jul 22 2010, 4:26 am
In response to Garthor
Infinite loops are not any more prone to causing lag than other code. Like anything, you need to consider how often the code will run and what the code does. If your attack command does some really complex calculations and you let players attack every tick, it could cause significant lag even though it's not an infinite loop.

Write the code and see if it is laggy. If it is, try to figure out why (do you need more of a delay between iterations? are you doing too much work each iteration?). Once you have the code written you can also ask for suggestions on ways to cut down on the lag. Without knowing what you're trying to do (or if it would even be laggy) it's hard to suggest ways to help.

As Garthor tried to suggest, this is a bad way to create infinite loops:

proc
  badloop()
    // execute some code here
    sleep(5)
    badloop()


The reason is that every time you call a proc, BYOND needs to remember what proc you came from (so when the second proc ends you can return to the right spot in the first proc). This list of locations to return to takes up memory. The badloop proc doesn't end, it just keeps calling itself, so this list will grow and grow. After enough iterations of the loop, you'll run out of memory! The other two methods are better because they avoid this problem.

Garthor wrote:
// BAD:
> proc
>   badloop()
>     blah blah blah
>     goodloop()
> 
> // GOOD:
> proc
>   goodloop()
>     while(1) // or for()
>       blah blah blah
> 
> // I SUPPOSE ACCEPTABLE BUT REALLY I THINK IT'S SLOPPY AND WASTEFUL
> proc
>   mehloop()
>     blah blah blah
>     spawn() mehloop()


badloop calls goodloop? That's a little redundant, but not as bad as you probably meant it to be. Since none of these loops have delays they're all bad.

I think you should look into the issue more, too. Spawn looks like it creates another thread, but really it just schedules the delayed execution of a block of code (which is what sleep does). The underlying layers don't need to use multiple threads to give us the illusion of multiple threads.