<p>Image-based programming systems like Smalltalk tend to try to be totalising closed worlds, but inevitably there will be <em>some</em> need to interact with the outside. For example, code will be accessing a network connection, file handle, or database cursor: these references to the outside world won't be valid any more after storing and resuming the image.</p>
<p>Other languages deal with these sorts of references by making them unserialisable. That isn't an option for these systems (or is it?), because the entire &quot;world&quot; is serialised when execution stops, or even while it's happening. From the program's perspective, it's been running the whole time, even after a lengthy pause.</p>
<p>What happens when an image resumes execution while invalidated references are held in variables? Are they transparently nulled out, do they error when accessed, or does this situation just never arise in the first place by construction?</p>

<smalltalk><serialization>
How do image-based languages deal with transient external references?
CC BY-SA 4.0
2023-10-30T18:01:07.263Z
It is not quite on-topic enough for an answer, but the E language has [sturdy references](http://www.erights.org/elib/concurrency/refmech.html), which are somewhat like cryptographic keys or URLs. A sturdy reference must be brought back to life prior to usage, and instantiating it can fail; in return, they are trivially serializable.
Corbin
CC BY-SA 4.0
2023-11-12T05:58:51.063Z
When I saw the title, I thought you meant esolangs like Piet.
Karl Knechtel
<p>In a Smalltalk such as <a href="https://pharo.org/" rel="noreferrer">Pharo</a>, typically the image file format is just a direct snapshot of the virtual machine state. Therefore, any object (including call stack frames) can be persisted in this way, but if it represents the state of an external resource, then the system needs to resynchronise the objects with the true state. Sometimes, yes, this means reacquiring resources from the operating system—or, in the case of <a href="https://www.gnu.org/software/smalltalk/" rel="noreferrer">GNU Smalltalk</a>, giving up on resuming execution exactly so as to play nicer with the host system. This design is inherited from the original Smalltalk, which was expected to serve as the operating system itself, so it didn’t need to worry as much about the mismatch in resource models.</p>
<p>If your object needs to do this, you can use the message <code>Smalltalk&gt;&gt;#addToStartUpList</code> to register a class for the runtime to notify, by sending the messages <code>startUp</code> and <code>shutDown</code>, whenever the image is reloaded or hibernated.</p>

CC BY-SA 4.0
2023-10-25T20:30:33.320Z
2023-10-25T20:36:00.603Z
2023-10-25T20:36:00.603Z
Jon Purdy
<p>The best way to think of this is that an image is like a virtual machine, and savings/loading is like hibernating or rebooting the machine. And just like that, it often doesn't make sense to have transient external resources persist. For instance, if you reboot a computer or VM, any open network connections or files become invalid.</p>
<p>The primary exception is the connection to the main user interface. Just as a computer's boot sequence reinitializes the console connection, when you resume an image the runtime will reconnect the handles for &quot;standard input&quot; and &quot;standard output&quot; in the new environment.</p>
<p>In most languages, resources other than stdin/stdout/stderr are not specified in the language definition at all, they're handled by libraries. Image-based languages may provide hooks for libraries so they can provide code to run at save/resume time. So if it does make sense for a library to provide external resources that are preserved, it can use these hooks to reinitialize.</p>

CC BY-SA 4.0
2023-10-25T20:29:38.163Z
2023-10-25T20:29:38.163Z
Barmar
CC BY-SA 4.0
2023-10-26T13:41:08.220Z
Yes, the problem is essentially identical to unplugging cables / devices on a hibernated laptop.
Jörg W Mittag
CC BY-SA 4.0
2023-10-27T11:38:02.470Z
@JörgWMittag Good analogy! I've wondered before what would happen if I hibernated my *desktop* and then upgraded the hardware. More RAM? New hard drive? DVD burner? How would the OS handle those? I assume not well, so I always shut it down properly. Making an OS that can handle this seems like a reasonable research question. The OS has no problem re-detecting hardware on resume from hibernate - the open research problem would be how to re-link it to application processes.
Criticize SE actions means ban
CC BY-SA 4.0
2023-10-27T14:49:01.780Z
@user253751 It's probably similar to removing a flash drive while the system is running, without cleanly unmounting it.
Barmar
CC BY-SA 4.0
2023-10-31T20:55:18.003Z
@Barmar But it's not expecting SATA drives to disappear while the computer is "running". The SATA bus driver might not like that - or new devices - while the USB bus driver is designed for it.
Criticize SE actions means ban
CC BY-SA 4.0
2023-10-31T21:07:03.640Z
@user253751 Actually, my Mac complains if I disconnect a  USB drive without unmounting. But I suspect the code for sleep/hibernate quiesces all drives, so it won't complain if they're disconnected while sleeping. And saving images probably works similarly.
Barmar
# How do image-based languages deal with transient external references?
Posted by: username_0 on 2023-10-25
Image-based programming systems like Smalltalk tend to try to be totalising closed worlds, but inevitably there will be *some* need to interact with the outside. For example, code will be accessing a network connection, file handle, or database cursor: these references to the outside world won't be valid any more after storing and resuming the image.

Other languages deal with these sorts of references by making them unserialisable. That isn't an option for these systems (or is it?), because the entire "world" is serialised when execution stops, or even while it's happening. From the program's perspective, it's been running the whole time, even after a lengthy pause.

What happens when an image resumes execution while invalidated references are held in variables? Are they transparently nulled out, do they error when accessed, or does this situation just never arise in the first place by construction?
**Tags:** smalltalk serialization
> **Comments:**
> **username_1**: It is not quite on-topic enough for an answer, but the E language has [sturdy references](http://www.erights.org/elib/concurrency/refmech.html), which are somewhat like cryptographic keys or URLs. A sturdy reference must be brought back to life prior to usage, and instantiating it can fail; in return, they are trivially serializable.  
> **username_2**: When I saw the title, I thought you meant esolangs like Piet.  
---
## 2 answers
### Answer by username_3 on 2023-10-25. Score: 13
In a Smalltalk such as [Pharo](https://pharo.org/), typically the image file format is just a direct snapshot of the virtual machine state. Therefore, any object (including call stack frames) can be persisted in this way, but if it represents the state of an external resource, then the system needs to resynchronise the objects with the true state. Sometimes, yes, this means reacquiring resources from the operating system—or, in the case of [GNU Smalltalk](https://www.gnu.org/software/smalltalk/), giving up on resuming execution exactly so as to play nicer with the host system. This design is inherited from the original Smalltalk, which was expected to serve as the operating system itself, so it didn’t need to worry as much about the mismatch in resource models.

If your object needs to do this, you can use the message `Smalltalk>>#addToStartUpList` to register a class for the runtime to notify, by sending the messages `startUp` and `shutDown`, whenever the image is reloaded or hibernated.
---
### Answer by username_4 on 2023-10-25. Score: 7
The best way to think of this is that an image is like a virtual machine, and savings/loading is like hibernating or rebooting the machine. And just like that, it often doesn't make sense to have transient external resources persist. For instance, if you reboot a computer or VM, any open network connections or files become invalid.

The primary exception is the connection to the main user interface. Just as a computer's boot sequence reinitializes the console connection, when you resume an image the runtime will reconnect the handles for "standard input" and "standard output" in the new environment.

In most languages, resources other than stdin/stdout/stderr are not specified in the language definition at all, they're handled by libraries. Image-based languages may provide hooks for libraries so they can provide code to run at save/resume time. So if it does make sense for a library to provide external resources that are preserved, it can use these hooks to reinitialize.
> **Comments:**
> **username_5** (2023-10-26): Yes, the problem is essentially identical to unplugging cables / devices on a hibernated laptop.  
> **username_6** (2023-10-27): @JörgWMittag Good analogy! I've wondered before what would happen if I hibernated my *desktop* and then upgraded the hardware. More RAM? New hard drive? DVD burner? How would the OS handle those? I assume not well, so I always shut it down properly. Making an OS that can handle this seems like a reasonable research question. The OS has no problem re-detecting hardware on resume from hibernate - the open research problem would be how to re-link it to application processes.  
> **username_4** (2023-10-27): @user253751 It's probably similar to removing a flash drive while the system is running, without cleanly unmounting it.  
> **username_6** (2023-10-31): @Barmar But it's not expecting SATA drives to disappear while the computer is "running". The SATA bus driver might not like that - or new devices - while the USB bus driver is designed for it.  
> **username_4** (2023-10-31): @user253751 Actually, my Mac complains if I disconnect a  USB drive without unmounting. But I suspect the code for sleep/hibernate quiesces all drives, so it won't complain if they're disconnected while sleeping. And saving images probably works similarly.  
---
