463 posts
Location
Star Wars
Posted 16 March 2016 - 02:13 PM
VERSION:Computercraft 1.78 (I think in any versions with the parallel API) [SSP]
DESCRIPTION:parallel offers an endless loop, and CC can use more than Windows allows, sometimes it freezes the computer.
EXPECTED RESULT:—
REPRODUCTION STEPS:WARNING, the following code use at your own risk:Spoiler
s = 0
function one()
s = s + 10
b = s
parallel.waitForAll(one, two)
end
function two()
b = s + b
s = b
parallel.waitForAll(one, two)
end
parallel.waitForAll(one, two)
The variables are for clarification.
Edited on 16 March 2016 - 01:55 PM
2427 posts
Location
UK
Posted 16 March 2016 - 03:03 PM
Why would you even make a program which does that?
463 posts
Location
Star Wars
Posted 16 March 2016 - 03:25 PM
When somebody uses the parallel API, for example for multi threading, this could happen.
3057 posts
Location
United States of America
Posted 16 March 2016 - 03:45 PM
Actually the reason this occurs is the fact that you are starting an infinite number of coroutines which never yeild nor return. Under normal usage, it won't break, and AFAIK it's impossible to not overload RAM when you make an infinite amount of something.
1426 posts
Location
Does anyone put something serious here?
Posted 16 March 2016 - 03:57 PM
This isn't an issue to do with RAM but rather to do with infinite loops and CC's "too long without yielding" error.
A standard infinite loop looks something like:
while true do end
After about 7-8 seconds your computer will be stopped as it has been running for too long.
A slightly more fancy version might look like. This is just the same as above but it utilises tail recursion.
local function foo()
return foo()
end
foo()
Your code above boils down to this: Note the similarity with the tail recursive version.
local function foo()
return coroutine.resume(coroutine.create(foo))
end
Whilst this is similar to other infinite loops, CC's timeout prevention doesn't appear to function 100% correctly and it appears to timeout after about 10-15 seconds instead. I'd have to do some profiling to see if this is the case though.
463 posts
Location
Star Wars
Posted 16 March 2016 - 05:07 PM
But this loop never be stopped by CC, that's the problem.
2427 posts
Location
UK
Posted 16 March 2016 - 05:31 PM
Why would you even make a program which does that?
When somebody uses the parallel API, for example for multi threading, this could happen.
having a coroutine manage a copy of itself is just asking for trouble in my opinion, and I still can't figure out any applications for this
Edited on 16 March 2016 - 04:32 PM
1426 posts
Location
Does anyone put something serious here?
Posted 16 March 2016 - 05:37 PM
But this loop never be stopped by CC, that's the problem.
Are you sure? I'd done some testing and it still terminates after a 10-15 seconds. This is much longer than it should be though.
463 posts
Location
Star Wars
Posted 16 March 2016 - 06:59 PM
Why would you even make a program which does that?
When somebody uses the parallel API, for example for multi threading, this could happen.
having a coroutine manage a copy of itself is just asking for trouble in my opinion, and I still can't figure out any applications for this
You can use it for listeners:
local list = {}
function connector()
local id, protocol = rednet.receive()
list[id] = protocol
local function listener()
while true do
local _, code = rednet.receive(list[id])
dostring(code)
end
end
parallel.waitForAll(connector, listener)
end
connector()
Granted, this Code is bad, but beginner may do this.
Edited on 16 March 2016 - 06:00 PM
2427 posts
Location
UK
Posted 16 March 2016 - 07:17 PM
Granted, this Code is bad, but beginner may do this.
who will then encounter the same error that you did and then post on ask a pro and be shown a better way to do that
I don't think this bug is worth fixing as it is a symptom of bad coding
Edited on 16 March 2016 - 06:19 PM
463 posts
Location
Star Wars
Posted 16 March 2016 - 07:49 PM
Okay