View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000691 | LDMud | Other | public | 2009-10-15 09:57 | 2009-10-26 11:39 |
| Reporter | _xtian_ | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | not fixable | ||
| Summary | 0000691: ability to abort running garbage_collection() | ||||
| Description | Since in http://mantis.bearnip.com/view.php?id=673 it was stated that there is no easy way to speed-up garbage-collection but there still is the problem that it may take hours, I think that it would be nice to have a way to abort the garbage_collection - maybe with an external signal, say USR2. (since USR1 already invokes a master-function) In more detail, what I need is a way to stop the GC and a) either resume clean operations OR b) start to save player-states and inventory (give me enough time for this) and shut the driver down. | ||||
| Additional Information | Another way to implement this could be to offer privileged efuns abort_garbage_collection() or similar. But this will only work if there is a way to cleanly restore the system to a correct state, of course. I am not familiar with the internals of the GC. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
Interuptable GC with our current system seems difficult to me, because all the reference counters are inconsistent if you abort the GC run. Which means, that neither a) nor b) will work. An efun is also not possible, because the driver does not execute LPC programs during the GC. That is actually a requirement currently. |
|
|
Hm, even if the refcounts are all off, can't you give me just one cycle? - and then immediately kill the driver? |
|
|
The refcounts and refmarkers are zeroed in the beginning of the garbage collection. And during normal LPC processing, data entities are free'd once their refcounts reach <=0. So if we abort the GC and continue execution even for once backend cycle, it is very likely that many entities are instantaneously free'd which are still in use. This can only work if we disable all freeing, which will add overhead to someting done quite often. |
|
|
For our current collector I am inclined to close this as not fixable. Any other comments? |
|
|
Ok, no other comments. So closing this as "can't fix" for the moment. This may change in the future with a different garbage collector. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-10-15 09:57 | _xtian_ | New Issue | |
| 2009-10-15 11:30 | zesstra | Note Added: 0001520 | |
| 2009-10-15 12:42 | _xtian_ | Note Added: 0001521 | |
| 2009-10-16 01:47 | zesstra | Note Added: 0001523 | |
| 2009-10-21 14:53 | zesstra | Note Added: 0001546 | |
| 2009-10-26 11:39 | zesstra | Note Added: 0001555 | |
| 2009-10-26 11:39 | zesstra | Status | new => closed |
| 2009-10-26 11:39 | zesstra | Resolution | open => not fixable |
