[1.76pr2] Command usage may interfere with event system
BombBloke opened this issue · 13 comments
Resolving commands (from the commands API available to command computers) may interfere with the event system, seemingly at random.
The more that are requested between yields (eg by using commands.execAsync()), the less likely it becomes that the computer which executed the commands will receive all events that should be due to it (other computers in the world do not appear to be affected at all).
Most often task_complete events are affected, as they're the most common events flooding into the event queue while command-heavy scripts execute, but using eg os.startTimer() in an attempt to "time-out" while waiting for these events is a poor workaround - it's just as possible to miss the timer events as well!
A sample script can be found here:
It orders as many commands as are allowed by "commandLimit" (setblock'ing stone in the square directly above the system), and then yields until it detects a task_complete event (at which point it executes another command, resumes yielding, etc). This goes on until 10000 commands have been executed, and if 10000 task_complete events are detected in return, the script ends.
Often there's a mismatch in the number of events received and so the script never finishes. I find it has about a 9/10 chance of running to completion as-is (with "commandLimit" at 30). Changing "commandLimit" to ~100 decreases that to about a 2/3 chance, whereas ~230 is more like 1/2.
Other commands may be used (eg "tell" instead of "setblock") with much the same result, though I've not had problems with commands.getBlockInfo(). Regardless as to whether the resulting events are received, best I can make out the commands do always execute correctly and perform their proper function.
We can't just let an unlimited number of events be added to an event queue, there has to be a limit after which events will be lost. You're bumping up against this limit.
write a simpler program using os.queueEvent that demonstrates commands
being lost with only 30 in the queue
On 11 December 2015 at 16:02, Bomb Bloke [email protected] wrote:
30 events in the queue is "bumping up against the limit"?
—
Reply to this email directly or view it on GitHub
#36 (comment)
.
Just dug into the code (it's very old code) and done some of my own
testing: the limit is 256 per computer. Here's the test program I used:
http://pastebin.com/9Y00ajAX
On 11 December 2015 at 16:04, Daniel Ratcliffe [email protected] wrote:
write a simpler program using os.queueEvent that demonstrates commands
being lost with only 30 in the queueOn 11 December 2015 at 16:02, Bomb Bloke [email protected] wrote:
30 events in the queue is "bumping up against the limit"?
—
Reply to this email directly or view it on GitHub
#36 (comment)
.
Compare:
Versus:
I find the former runs indefinitely, while the latter freezes within a minute.
Modified by program to demonstrate command complete events are subject to
the same limits: http://pastebin.com/VyqqqDn4
On 11 December 2015 at 16:14, Bomb Bloke [email protected] wrote:
Compare:
Versus:
I find the former runs indefinitely, while the latter freezes within a
minute.—
Reply to this email directly or view it on GitHub
#36 (comment)
.
Running your second program. Is running indefinitely just fine.
On 11 December 2015 at 16:18, Bomb Bloke [email protected] wrote:
Yes, I'm aware of the 256 event cap. This issue is unrelated.
—
Reply to this email directly or view it on GitHub
#36 (comment)
.
scratch that, just saw an concurrentmodificationexception in the output,
investigating
On 11 December 2015 at 16:19, Daniel Ratcliffe [email protected] wrote:
Running your second program. Is running indefinitely just fine.
On 11 December 2015 at 16:18, Bomb Bloke [email protected] wrote:
Yes, I'm aware of the 256 event cap. This issue is unrelated.
—
Reply to this email directly or view it on GitHub
#36 (comment)
.
I don't know how much it helps, but I've been able to reproduce right back to the oldest build I've got with Command Computer access. 1.66pr3 if I haven't got myself confused.
Edit: I'm afraid I'm up well past my bedtime, so I'll leave off for the night. Thanks for looking into it.
Fixed the CME exception. Just ran your original program 5 times in a row with commandLimit set to 200. I think this is fixed. Let me know here if you still have trouble once 1.67pr3 hits.