View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000447 | LDMud 3.5 | Implementation | public | 2006-03-01 14:17 | 2012-07-12 21:10 |
Reporter | Assigned To | ||||
Priority | normal | Severity | minor | Reproducibility | always |
Status | new | Resolution | open | ||
Summary | 0000447: Heartbeat interval should be configurable | ||||
Description | MudOS for example allows that. | ||||
Tags | No tags attached. | ||||
|
I assume, the intention is to allow individual HB intervals for objects, as the global interval is already configurable? Might then be something for 3.5 if we have to change the HB processing in the backend cycle, maybe to something similar to the callout processing. |
|
On the other hand: maybe it is sufficient to just use callouts for the objects with different timings? I am not sure if benefit is worth re-working the HB mechanism...? |
|
Opinion from the peanut gallery (yes, it exists): IIRC, the difference between heartbeats and call_outs is that heartbeats are executed only to fill up current polling interval. Any heartbeat not fitting into the current polling interval is pushed with priority into the next one; allowing the game to degrade gracefully under load. call_outs on the other hand are executed at their trigger time, no matter how long it takes. To truly replace heartbeats with call_outs, you'd have to implement a 'BEST_EFFORT_TIMING' kind of flag. (Again, I might be completely wrong - I'm writing from memory here. And if that is indeed the case, let me know, and I'll shut up :) ) |
|
Depends on how much work it would be. If it's easily done, configurable heartbeat might be a nice feature. OTOH the time may better be invested into a more generic, HB-independent timer/event-system. I agree it is feasible to solve this with call_outs though (I did it for RoleMUD's dynamic attribute system). |
|
Making heart_beat time intervals configurable would give you best of both worlds: one the one hand, call_outs at guaranteed configurable times, and on the other hand, heartbeats at load-aware best-effort configurable times (plus, heartbeats automatically reoccur, call_outs don't). In theory both could be unified into the same efun, but I'd make that step 2. |
|
This feature can be implemented rather easily, because there is an object list sorted after their individual call schedules. (When using asynchronous heartbeats.) Two changes are required: Instead of storing the time of the last hb execution, store the time of the scheduled call. And instead of adding new objects to the end of the list insert it at the appropriate place for its schedule. (Bonus: When changing the interval, move the object to its new place.) |
Date Modified | Username | Field | Change |
---|---|---|---|
2006-03-01 14:17 |
|
New Issue | |
2008-07-01 03:28 | zesstra | Note Added: 0000643 | |
2008-07-16 16:27 | zesstra | Project | LDMud => LDMud 3.5 |
2012-06-09 10:04 | zesstra | Note Added: 0002137 | |
2012-06-09 10:04 | zesstra | Status | new => feedback |
2012-06-10 01:19 |
|
Note Added: 0002138 | |
2012-06-10 01:19 |
|
Status | feedback => new |
2012-06-10 11:52 | invisible | Note Added: 0002139 | |
2012-06-16 22:24 |
|
Note Added: 0002140 | |
2012-07-12 21:10 | Gnomi | Note Added: 0002146 |