[Devel] Feature request: error/debug message extension.
Gabriel M. Beddingfield
gabrbedd at gmail.com
Sat Jan 14 15:52:19 PST 2012
On 01/14/2012 02:48 PM, David Robillard wrote:
>> a. Adopt sprintf() syntax, which I don't believe can be implemented
>> in a RT-safe manner.
> Obviously standard syntax would be used.
> It is certainly possible to implement in an RT-safe manner, though the
> stdlib functions may not be.
So we want to put *THAT* complexity on the host??
> 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".
OK, but the plugin can use a simplified syntax for dynamic strings.
Proof of concept: RtString<T>
>> 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
> I guess this would do. Yet more complexity...
...and optional complexity on the part of the plugin. If they want to
use a slow-ass query function, they can have at it.
>> 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.
You've misunderstood me, I think. My dynamic strings I mean, "strings
that can be manipulated to print numbers and sunch."
> 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.
The plugins have the option of NOT using printf & co. for their
strings... but can still have string formatting.
> 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.
OK with me.
More information about the Devel