blob: 0bd881fe16e48f16bda5fe47cca518105baabed4 [file] [log] [blame]
MG Mud User88f12472016-06-24 23:31:02 +02001SYNOPSIS
Zesstra7ea4a032019-11-26 20:11:40 +01002 void dangling_lfun_closure()
MG Mud User88f12472016-06-24 23:31:02 +02003
4DESCRIPTION
Zesstra7ea4a032019-11-26 20:11:40 +01005 Handle a dangling lfun-closure.
MG Mud User88f12472016-06-24 23:31:02 +02006
Zesstra7ea4a032019-11-26 20:11:40 +01007 This is called when the gamedriver executes a closure using a
8 vanished lfun, with previous_object() showing the originating
9 object. A proper handling is to raise a runtime error.
MG Mud User88f12472016-06-24 23:31:02 +020010
Zesstra7ea4a032019-11-26 20:11:40 +010011 Technical:
12 Upon replacing programs (see efun replace_program()), any
13 existing lambda closures of the object are adjusted to the
14 new environment. If a closure uses a lfun which vanished in
15 the replacement process, the reference to the lfun is
16 replaced by an alien-lfun closure referencing to this function.
17 The error will then occur when the execution of the adjusted lambda
18 reaches the point of the lfun reference. There are two reasons for
19 the delayed handling. First is that the program replacement and with
20 it the closure adjustment happens at the end of a backend cycle,
21 outside of any execution thread: noone would see the error at this
22 time. Second, smart closures might know/recognize the program
23 replacement and skip the call to the vanished lfun.
24
25HISTORY
26 Since LDMud 3.2.9, all references to dangling_lfun_closure() are
27 created as alien-lfun closures.
MG Mud User88f12472016-06-24 23:31:02 +020028
29SEE ALSO
Zesstra7ea4a032019-11-26 20:11:40 +010030 closures(LPC)