Here's another one of those things that I can't believe hasn't bitten me yet... or maybe it has and I didn't know it!
I don't know if this is a feature request exactly. More of an invitation to discussion of whether or not it should be a feature request.
spawn() and sleep() work on absolute time. spawn(300) waits for 30 seconds, then awakens on whatever tick is closest to 30 seconds later.
However, when I use spawn() and sleep(), I commonly (in fact, almost always) use them with ticks in mind, rather than real tenths of a second. So the following code produces some interesting results:
world
tick_lag = 5
New()
. = ..()
spawn(1) world << "Step 1 at [world.time]"
spawn(3) world << "Step 2 at [world.time]"
spawn(5) world << "Step 3 at [world.time]"
spawn(7) world << "Step 1 at [world.time]"
spawn(9) world << "Step 2 at [world.time]"
spawn(11) world << "Step 3 at [world.time]"
spawn(13) world << "Step 1 at [world.time]"
spawn(15) world << "Step 2 at [world.time]"
spawn(17) world << "Step 3 at [world.time]"
And the results:
Step 1 at 0
Step 2 at 0
Pager on.
Step 3 at 5
Step 1 at 5
Step 2 at 5
Step 3 at 10
Step 1 at 10
Step 2 at 15
Step 3 at 15
I considered using #define to create "spawnt" and "sleept", which would multiply the supplied value by tick_lag. If you use sleept(4) and tick_lag is 5, you'd wait 20 ticks -- that way at least every sleep/spawn would stay on the same scale relative to all others. But there's a flaw in that: tick_lag could change during the course of the game, while procs are sleeping.
So my question is: does it make sense to add spawnt and sleept (or whatever) as functions that guarantee the exact tick on which they will awaken?
ID:259214
 Sep 6 2000, 3:32 pm
|
|
On 9/6/00 8:36 pm Guy T. wrote:
I'm having a hard time verbalizing it, but basically my theory is that tick_lag ends up being irrelevant, because everything will still end up executing in the order it should, relative to other sleeping procs. But another part of my mind says this is too simple. Is that good or bad? My brain is too tired right now to figure it out! I wasn't even aware that spawn/sleep weren't in ticks. I guess a fixed time makes more sense. I only started messing around with tick_lag tonight (and in the other direction). It should be interesting to see if the timing actually works. | |
Is that good or bad? My brain is too tired right now to figure it out! Mine is too, and I've been awake for hours now... I think I also described the question poorly. Say I spawn two separate procs, one with a delay of 1 and one with a delay of 2. I do this because the first has to do some preprocessing -- maybe the first generates random names for all the Goblins in the world, and the second puts their names in the Book of Goblins. But if tick_lag is set to 3, is there a chance that the Book could be compiled before their names were generated? (Of course, I guess it would be pretty funny to open the Book of Goblins and read "Goblin, Goblin, Goblin, Goblin, Goblin...") I wrote a program to test this right after I woke up this morning... but since I'm not a morning person, I had no idea how to interpret the results. I'll try to look at it tonight! | |
Maybe the real question is this. By writing with ticks in mind, I'm planning on things happening in a certain order. The more I think about it, the more I suspect that -- since the sleeping procs are executed in a first-in, first-out order -- the actual realtime timing doesn't matter. For example, if I call A with spawn(1), B with spawn(2), and C with spawn(3), and then 2 ticks later B calls D with spawn(1), I think I'll get the result that A executes, then B, then C, then D, even if tick_lag is set to a million.
I'm having a hard time verbalizing it, but basically my theory is that tick_lag ends up being irrelevant, because everything will still end up executing in the order it should, relative to other sleeping procs. But another part of my mind says this is too simple.