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

David Robillard d at drobilla.net
Sat Jan 14 12:48:48 PST 2012


On Sat, 2012-01-14 at 09:39 -0600, Gabriel M. Beddingfield wrote:
> 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.

Obviously standard syntax would be used.

It is certainly possible to implement in an RT-safe manner, though the
stdlib functions may not be.

I don't really think making the API vastly more annoying to use in a
plugin in order to achieve printing in realtime - which is a pretty
silly thing to do in the first place - is a very good trade-off.

Regardless, that argument is basically "this is hard, so we should force
plugins to do it", which is backwards.  Like it or not, code is going to
have to do format-string-like things in order to print anything useful.
To say otherwise is like saying "nobody will need to print numbers".

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

I guess this would do.  Yet more complexity...

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

Yes, but this again ignores the overwhelmingly important issue that only
being able to print a single string *isn't useful*.  People simply need
to print numbers and such.

Let's be realistic - not providing a useful print API capable of dealing
with parameters means that people will resort to the solution you did -
using snprintf on a static buffer.  If this isn't realtime safe either,
what's been won?

As always, where there is a choice, complexity belongs in the host.
Making every plugin include a realtime-safe printf implementation would
be absurd.

If we want to avoid requiring the implementation of that entirely, we
can simply just forbid using any arguments in the realtime thread.  No
sense castrating the API in other contexts for this border case.

-dr




More information about the Devel mailing list