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

[Gabriel M. Beddingfield]

On 01/12/2012 04:09 PM, Paul Giblock wrote:
>> This would let the host do pretty much anything (by putting whatever in
>> the handle), but also make a trivial implementation extremely simple
>> (you could literally use pointers to printf and vprintf with a FILE*
>> handle if you just want to print to stdout anyway).
>
> Yes, although the trivial solution is inherently not real-time safe.
> Good to still have the option for a host to be quick and careless
> though.

...but if there are limits to the size of the string (either imposed by 
convention, the host, or the plugin), then this can be done RT safe.

I'm not sure what to think about the hosts being required to supply 
fprintf-style formatting... I think the plugins themselves should format 
their own strings and the host just bit-blits them to its internal 
ringbuffer.  If you want snprintf()... just use snprintf().  I'm pretty 
sure it's OK for plugins to use std C lib, right?  :-p

For example:

#define MY_LOG_FUNC(fmt, ...) {                        \
     char s[ARBITRARY_LENGTH];                          \
     snprintf(s, ARBITRARY_LENGTH, fmt, ##__VA_ARGS__); \
     host_supplied_log_func(s);                         \
}

I dunno if snprintf() is realtime safe[1]... but allocating short 
strings on the stack *is* realtime safe.

>> One thing this does not address, though, is multiple streams e.g. for
>> errors, warnings, and info messages.
>
> I wonder if extensibility of the different streams is necessary or
> not? I'm thinking "no".  We could allow mapped URIs for the different

I'm thinking "yes."

> streams, and predefine a few (error, warn, and info)?  But, if you
> study the popular Log4j or java.util.logging Java packages, it seems
> people are happy enough with: Fatal, Error, Warn, Info, Debug, Trace.
> I'm suggesting one more argument before the format string for the
> enumerated value of the stream. (The java logging packages seem to
> call these logging "levels").

I agree with adding an arg for debug level.

> Finally, I feel it is a good idea to support the format-string and
> varg variants. Not only are the plugins relieved from the duty of
> string-banging while in RT mode, but the host is able to short-circuit
> the whole thing should the level be under some threshold.

I usually do short circuiting with a macro like this:

#define LOG(cond, fmt, ...) { \
     if(cond) { log_function(fmt, ##__VA_ARGS__); } \
}

At runtime, an integer check-and-jump is faster than a function call. 
This fast short-circuit can only be done by a macro, not a function call.

So... I suggest that thought be put in to some manner of log-level 
management.  (Yeah, just the sound of it sounds too complicated, but you 
know...)  I can envision times when I want:

     Log output level:  Debug
     Host logging level: Error
     Plugin Z's logging level: Debug
     Plugin Y's logging level: Verbose
     All other plugins:  Silent

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.

-gabriel

[1] It's not in the list of async-safe functions, so probably not.  It 
probably uses malloc() somewhere.  See signal(7).