8 Jan
2010
8 Jan
'10
8:55 a.m.
Regarding LADI Level 1...
On Fri, 8 Jan 2010, rosea grammostola wrote:
> In signal handler function, a global variable can
be set to mark that
> save is needed. On next main loop iteration, the global variable is
> checked and eventually save is made.
This totally confused me at first. "You're sending me a
UNIX signal... but then I'm supposed to answer back by
allocating a global variable? How do I do that?"
I think what you mean is to indicate that saving doesn't
have to happen in realtime, but that it can happen (for
instance) as part of the program's normal event loop. The
stuff about the global variable (or even an event loop) is
an implementation detail.
I suggest the wording be changed to say something like this:
"The application, after receiving the signal, should
save as soon as possible. However, the saving does
not have to happen in the signal-handler function
itself. (For example, you can push a 'Save Event' to
your normal event loop.)
> Save of the internal state can be made in a fixed
file path, but it is
> more useful to supply the file path through commandline. When
> starting, app loads its internal state from the file specified. When
> saving, app saves its internal state to the file specified."
This is also confusing wording (to me). Who is setting this
file path? And the commandline?? I thought we were
handling a signal.
May I suggest the following wording:
"The application is free to save state however it
sees fit (e.g. saving files to a fixed file path).
When the application is started, some means of
restoring the state needs to be given to the user,
preferably from the commandline. For example,
when the signal is received, the application will
give a string id (such as a file path) to the
user. This id may then be used as a commandline
argument to restore the state."
I think this is a good idea (Nedko or whoever dreamed it
up), and I'm willing to add it to my applications.
Peace,
Gabriel