17
$\begingroup$

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?

$\endgroup$
2
  • $\begingroup$ It is not quite on-topic enough for an answer, but the E language has sturdy references, 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. $\endgroup$ Commented Oct 30, 2023 at 18:01
  • 1
    $\begingroup$ When I saw the title, I thought you meant esolangs like Piet. $\endgroup$ Commented Nov 12, 2023 at 5:58

2 Answers 2

Reset to default
13
$\begingroup$

In a Smalltalk such as Pharo, 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, 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.

$\endgroup$
7
$\begingroup$

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.

$\endgroup$
5
  • 4
    $\begingroup$ Yes, the problem is essentially identical to unplugging cables / devices on a hibernated laptop. $\endgroup$ Commented Oct 26, 2023 at 13:41
  • $\begingroup$ @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. $\endgroup$ Commented Oct 27, 2023 at 11:38
  • $\begingroup$ @user253751 It's probably similar to removing a flash drive while the system is running, without cleanly unmounting it. $\endgroup$ Commented Oct 27, 2023 at 14:49
  • $\begingroup$ @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. $\endgroup$ Commented Oct 31, 2023 at 20:55
  • $\begingroup$ @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. $\endgroup$ Commented Oct 31, 2023 at 21:07

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.