[LAD] Session Handlers and 'level 1' support

Gabriel M. Beddingfield gabrbedd at gmail.com
Fri Jan 8 12:55:17 UTC 2010


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



More information about the Linux-audio-dev mailing list