Infinite Loop [RESOLVED]

ID:1398850
 
Oct 14 2013, 2:40 pm (Edited on Oct 14 2013, 3:36 pm)
(See the best response by Ter13.)
Code:
/mob/creature/proc/Movement()
    if(destination)
        step_to(src, destination)
        sleep(1.5)
        src.Movement()
    if(!owner)
        step_rand(src)
        sleep(rand(3, 12))
        src.Movement()
    else
        sleep(10)
        src.Movement()


Problem description:
When actually causing a creature to move, this runtime error appears when the creature cannot get to its location.

http://www.privatepaste.com/6aa0cbc492

Here is the numbers in the profiler as a result...

http://www.privatepaste.com/a10c6d31fd

And then it crashes. I don't have much experience with this, and in fact it's my first time attempting something of the like. Does anyone have advice/explanation that can help?

(( Full source is available here: https://github.com/NicholasDM/realm-master ))

Oct 14 2013, 2:50 pm
Ok, 1st you should change that sleep() to a spawn()

Also, do you really need to have a inf. loop of this magnitude? you are literally making it repeat and repeat forever and it'll never end because to top it off you are calling another inf. loop on top of the one that never ended.

sleep(1.5)


This delay is absurdly low anyway, try changing the sleep() to a spawn on all of them like I stated earlier. But what exactly are you doing with this code, seems to me like this can be accomplished without having these inf. loops and making them repeat within 1 sec after they ended.
Oct 14 2013, 2:57 pm
I'm actually not aware if I'm calling another inf. loop on top of the one that never ended. This should cause a single infinite loop for every individual mob-- unless it lacks an owner and also lacks a destination, in which case I'm glad I just saw that.

Also-- for movement, the delay isn't quite absurdly low. While not ideal, the issue is constant even when the delay is as high as 50 or 100 (though it takes a bit longer to manifest). The low delay for this does make it easier to actually see what's going on. :P

Though I can get the same effect of seeing what's going on by decreasing the delay and increasing the pixel step. That is a change that I likely will make.
Oct 14 2013, 2:59 pm
Add my skype : DontDreamLiveG , I'll help you fix
Oct 14 2013, 3:00 pm
In response to Blast3r
Best response
Blast3r wrote:
Ok, 1st you should change that sleep() to a spawn()

Also, do you really need to have a inf. loop of this magnitude? you are literally making it repeat and repeat forever and it'll never end because to top it off you are calling another inf. loop on top of the one that never ended.

sleep(1.5)

This delay is absurdly low anyway, try changing the sleep() to a spawn on all of them like I stated earlier. But what exactly are you doing with this code, seems to me like this can be accomplished without having these inf. loops and making them repeat within 1 sec after they ended.

All of this information is incorrect.

An infinite loop is not a problem. OP should be using while(), as opposed to recursion, otherwise you will wind up having a crash due to a stack overflow.

Spawn() will make it worse.

While() with a sleep at the end is just fine.

Blast3r is incorrect.
Oct 14 2013, 3:02 pm
In response to Blast3r
This will prevent the crash. There's no problem with an infinite loop like this, as it will cease when the object falls out of relevance.

/mob/creature/proc/Movement()
    while(src)
        if(destination)
            step_to(src, destination)
            sleep(1.5)
        if(!owner)
            step_rand(src)
            sleep(rand(3, 12))
        else
            sleep(10)
Oct 14 2013, 3:03 pm
No, I solved several of my inf loop crash issues by changing the sleep to spawn() , this was suggested by Galactic Soldier, and till this day it has always worked fine. When I use sleep it'd crash minutes in
Oct 14 2013, 3:06 pm
That's because sleep puts the entire proc on hold, and has to withhold the amount of processing from an infinite loop, as to where spawn is a countdown.

But still, what Ter mentioned is far more usefull. as the loop is created by the while statement, as long as src is present
Oct 14 2013, 3:09 pm
In response to Blast3r
Blast3r wrote:
No, I solved several of my inf loop crash issues by changing the sleep to spawn() , this was suggested by Galactic Soldier, and till this day it has always worked fine. When I use sleep it'd crash minutes in

Your understanding of what Galactic Soldier said was wrong.

It will wind up overflowing the stack, and it will under-perform compared to the while loop above.

Galactic Soldier isn't an impressive name to drop to back up poor programming practices either.
Oct 14 2013, 3:11 pm
Doesn't changing sleep to spawn make the code do 2 things at once (countdown for the spawn to work as well as continue on with the rest of the code), thus overburdering it?
Oct 14 2013, 3:15 pm
 
/mob/creature/proc/Movement()
    while (TRUE)
        if(destination)
            while(get_dist(src, destination) >= 1)
                step_to(src, destination)
                sleep(walk_delay)
        else if (!owner)
            while(!owner)
                step_rand(src)
                sleep(rand(10, 30))
        sleep(10)


Appeared, at first, to fix the issue. The same error pops up after a few minutes, however. I'm uncertain how to fix the issue, specifically, still.

I apologize for the trouble. :/
Oct 14 2013, 3:17 pm
In response to Dm31st3r
Dm31st3r wrote:
Doesn't changing sleep to spawn make the code do 2 things at once (countdown for the spawn to work as well as continue on with the rest of the code), thus overburdering it?

Spawn() takes the entire local scope of a function call and inserts it into the scheduler for later processing, while sleep() simply delays current processing in the scheduler.

They are similar, but it would be pointless to explain the differences here, as it would only further confuse people when it comes to standards and practices.

As a rule of thumb: Avoid use of spawn() unless you need to create what's called a coroutine type of behavior.
Oct 14 2013, 3:18 pm
In response to Dm31st3r
@OP: Also, set world.loop_checks to 0.

Read the runtime error. If you are going to have an infinite loop running, the VM is not going to like you for it, too much.
Oct 14 2013, 3:21 pm
Fair enough, then! There appears to be no actual lag from it, so I suppose it isn't an issue. I appreciate the assistance.

Have a nice day!

(The quick help was very nice.)