[pulseaudio-discuss] introduce the new feature of ring buffer log and ask for comments

[rong deng]

Hi David,

Thanks for your comments, see my inlined comments below:

2012/8/14 David Henningsson <david.henningsson at canonical.com>:
> On 08/13/2012 04:59 PM, rong deng wrote:
>>
>> Ask for comments
>> ================
>>
>> We design this feature to try to be useful for users and developers. We'd
>> like
>> to hear from you how do you think. Please don't hesitate to give your
>> valuable
>> feedback!
>
>
> Hmm, maybe we could add the output of "pactl log" to bugs reported against
> the PulseAudio package in Ubuntu? That way maybe we don't have to ask for
> PulseAudio logs all the time...so yes, then it could be helpful!

Yes, this is one of our goals. In this way, developers only ask users
to give the output of 'pactl log', users don't bother to kill
PulseAudio and restart the daemon with somewhat verbose options.

>
> I have a few questions:
>
> 1) How will the existing log targets (log to file/syslog/stderr etc) work in
> this scenario? Are there any changes or is this two entirely separate
> logging systems?

These are two entirely separate things. You can disable this new
feature if you want. We provide this disabling feature to make sure
the performances of some embedded systems won't be hurt.

>
> 2) Somewhat related to question 1, what if the following happens:
>  * thread A writes to the debug log "Sending message to thread B"
>  * thread A sends the message to thread B
>  * thread B logs a warning message "Invalid message received"
>  * thread B crashes PulseAudio with sigsegv
> How can we ensure that both messages from thread A and thread B can be
> retreived after the crash? Is there a risk PulseAudio will not write both
> messages to disk before it crashes?

The current implementation is an in-memory log, so the logs would
vanish if it crashes.
But we can change this to a disk-based implementation, then even after
the crash the logs can be retrieved.

>
> 3) How long is the per-thread buffer by default (and is that in messages or
> characters)? Would it make sense to have this limit configurable (in what
> ways)?

For each thread, it contains 200 log messages with each message at
most 512 characters. As in the current implementation these numbers
are hard coded. It's doable to make it configurable, but it would
complicate the current code a lot. And it's best to configure it at
run time.