| MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | SYNOPSIS |
| 2 | void dangling_lfun_closure() |
| 3 | |
| 4 | DESCRIPTION |
| 5 | Handle a dangling lfun-closure. |
| 6 | |
| 7 | This is called when the gamedriver executes a closure using a |
| 8 | vanished lfun. A proper handling is to raise a runtime error. |
| 9 | |
| 10 | Technical: |
| 11 | Upon replacing programs (see efun replace_program()), any |
| 12 | existing lambda closures of the object are adjusted to the |
| 13 | new environment. If a closure uses a lfun which vanished in |
| 14 | the replacement process, the reference to this lfun is |
| 15 | replaced by a reference to this function. The error will |
| 16 | then occur when the execution of the adjusted lambda reaches |
| 17 | the point of the lfun reference. There are two reasons for |
| 18 | the delayed handling. First is that the program replacement |
| 19 | and with it the closure adjustment happens at the end of a |
| 20 | backend cycle, outside of any execution thread: noone would |
| 21 | see the error at this time. Second, smart closures might |
| 22 | know/recognize the program replacement and skip the call to |
| 23 | the vanished lfun. |
| 24 | |
| 25 | SEE ALSO |
| 26 | closures(LPC) |