[LAD] Session Handlers and 'level 1' support

[Nedko Arnaudov]

"Gabriel M. Beddingfield" <gabrbedd at gmail.com> writes:

> Regarding LADI Level 1...
>
>>> 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?"

It is said "set" not "allocate".

> 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.)

Good wording, thanks! I've updated http://ladish.org/wiki/level1

>>> 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."

Good wording again, I've put it on the wiki page with the correction
that "needs" is replaced with "could". There is no need, some apps
may want to operate on state in fixed location.

> I think this is a good idea (Nedko or whoever dreamed it 
> up), and I'm willing to add it to my applications.

What are your applications?

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100108/b2cb28b4/attachment.pgp>