[Devel] Feature request: error/debug message extension.

[Gabriel M. Beddingfield]

On 01/13/2012 06:19 PM, David Robillard wrote:
>> For example:
>>
>> #define MY_LOG_FUNC(fmt, ...) {                        \
>>       char s[ARBITRARY_LENGTH];                          \
>>       snprintf(s, ARBITRARY_LENGTH, fmt, ##__VA_ARGS__); \
>>       host_supplied_log_func(s);                         \
>> }
>
> Why make plugins do this?  Given the choice, complexity belongs in the
> host.

Because it means that LV2 either has to:

a. Adopt sprintf() syntax, which I don't believe can be implemented
    in a RT-safe manner.

b. Establish its own string formatting syntax.

I don't like either.  Let me know if you see another option.

>> This requires (at the very least) a callback to the plugin when we want
>> the plugin's log level to change.  Managing the rest is up to the host.
>
> The nice and simple-yet-extensible way of doing this would be to simply
> pass a function that takes a level URID and returns a bool, which is
> whether or not to log that function.
>
> This has overhead, of course.  I don't see any really sane way of
> getting a macro solution like the above, unless plugins cache it at
> instantiation time (meaning it couldn't be changed dynamically while
> running).

That's why I suggest that a callback to the plugin (or an event) is 
required.  When the logging level changes, the plugin is notified of the 
change.

>> [1] It's not in the list of async-safe functions, so probably not.  It
>> probably uses malloc() somewhere.  See signal(7).
>
> A wonderful example of exactly why crap like this shouldn't be the
> plugin's problem.  If a host can provide an RT safe print function, then
> that should be possible.  Every plugin shouldn't have a bunch of
> advanced realtime fancy business and custom print messages just to dump
> some log messages!

I agree... but see the reasons above are why I would prefer not to go there.

> Though, one could make the argument that printing in the audio thread is
> simply something you should not be doing anyway, unless you're
> debugging, in which case real-time safety doesn't matter...

I disagree.  Logging dynamic strings *can* be done RT-safe and with 
miniscule overhead.

-gabriel