[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