[Python-ideas] Application awareness of memory storage classes

[R. David Murray]

On Fri, 20 May 2016 13:17:57 +0200, Piotr Balcer <ppbbalcer at gmail.com> wrote:
> 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.
> 
> Piotr
> 
> 2016-05-20 12:30 GMT+02:00 Steven D'Aprano <steve at pearwood.info>:
> 
> > On Wed, May 18, 2016 at 01:44:12PM -0400, R. David Murray wrote:
> >
> > [...]
> > > The main target would of
> > > course be the data the program wants to preserve between runs, but one of
> > > the examples at pmem.io is a game program whose state is all in nvram.
> > > If the machine crashes in the middle of the game, upon restart you pick
> > > up exactly where you left off, including all the positioning information
> > > you might consider to be part of the "hot loop" part of the program.
> >
> > 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.

Also note that that's a limited subset of the possible ways things might
crash, even if it will likely be a common one in practice :)  In the
general case you'll need a way to clear the memory during development,
and/or have a "test memory" setup that will be cleared before each
test run and/or unit test.  You'll also want ways to simulate crashes
"at any point" (similar in principle to how Victor's memory tools can
be used to simulate Python running out of memory "at any point").

You may need additional tools built into your application to manage
the results of a crash.  Exactly what tools you will want for updating
the persistent state after various kinds of crashes is likely to
be application specific, as is the "automatic recovery" code you'll
build in to the application.

I'm sure that we'll evolve best practices, test libraries, and helpful
tools, for various problem domains, just as we have for working with
disk-based databases.  First we need to be able to write the code,
though.

--David