[Python-ideas] Application awareness of memory storage classes

Terry Reedy tjreedy at udel.edu
Fri May 20 16:06:03 EDT 2016

On 5/20/2016 7:17 AM, Piotr Balcer wrote:

[rearranged to undo top posting]

> 2016-05-20 12:30 GMT+02:00 Steven D'Aprano
>     Wouldn't that mean you're restarting the game in the same state it was
>     in just before it crashed? Which means (assuming the crash is
>     deterministic) the very next thing the game will do is crash.

> That's an excellent observation ;) This is actually what happend when we
> first wrote that game - there was a NULL-dereference in the game logic and
> it caused a 'persistent segmentation fault'. It's really important for
> programmers to step up when it comes to creating software that uses
> this type of memory directly. Everyone essentially becomes a file system
> developer, which is not necessarily a good thing.
> Our hope is that high level languages like python will also help in this
> regard by making sure that the programmer cannot shoot himself in the foot
> as easily as it is possible in C.

Unless one uses ctypes or buggy external C-coded modules, seg faulting 
is already harder in Python than C.

One possibility to make using persistent memory easier might be a 
context manager.  The __enter__ method would copy a persistent object to 
a volatile object and return the volatile object.  The body of the with 
statement would manipulate the volatile object. *If there are no 
exceptions*, the __exit__ method would 'commit' the changes, presumed to 
be consisting, by copying back to the persistent object.

with persistent(locator) as volatile:
     <manipulate volatile>

Ignoring the possibility of a machine crash during the writeback, a 
restart after an exception or crash during the block would start with 
the persistent object as it was before the block, which absent bugs 
would be a consistent state.

Terry Jan Reedy

More information about the Python-ideas mailing list