Scheduling vs UpdatesQueues

[Fox-McCloud]

@volundr-

Just a quick question for you, what, precisely is the advantage of running something through the update queue vs purely using the schedule or visa versa? Is there an inherent advantage to one over the other or a reason a particular control loop is better suited to using updatequeues vs scheduling? Thanks, in advance!

[volundr-]

The updateQueue is useful, but adds a bit of overhead. The overhead is involved in gracefully handling failures during updates of items in the queue. In essence, if an update hangs on an item in the queue, the rest of the queue is still processed with no issues. You would use this if you had a smallish number of items that may take a long time to update, or may hang while updating. Mobs, for instance. Goonstation has had problems with mob updates hanging the process, so we use updateQueue for that. Mobcode is nuts.

If you have a whole lot of objects that don't take a lot of time to update (machines, pipenets, etc), you don't want to use updateQueue. Just write a loop for those in the process and call scheck() inside the loop.

[Fox-McCloud]

@volundr-

Thanks a bunch, that helps clarify things a lot; much much appreciated!

[Fox-McCloud]

@volundr-

Just another quick question. For deferring process to the next tick (in update queues and scheck), wouldn't it be better/adventageous to defer it for world.tick_lag instead of 1 decisecond?

[volundr-]

When scheck decides to defer, the world tick is already going into overtime - deferring for the smallest interval makes it so that the work is simply pushed over into the next world tick, rather than pushing it forward a specific length of time. So deferring for tick_lag would actually push the work farther down the queue than desired.

[Fox-McCloud]

If that's the case then, why was one decisecond chosen? Why not lower, if you want to defer for the smallest interval possible? Correct me if I'm wrong, but wouldn't sleeping tick_lag be less than sleeping for one decisecond? (given that tick_lag is usually 0.9 deciseconds..though some servers utilize 0.5)

If I'm misunderstanding you here, I apologize!

[volundr-]

@Fox-McCloud That's a great question actually! I'll do some experiments and see what the effect of sleeping tick_lag versus 1 is.

[Fox-McCloud]

@volundr-

Great! Lemme know how it turns out!

[MrStonedOne]

Byond rounds sleep() to the next tick. so you can do sleep(0.01) to ensure you run next tick logical tick.