Daniel P. Berrangé <berrange@redhat.com> writes:
On Tue, Jan 13, 2026 at 10:49:01AM +0000, Daniel P. Berrangé via Devel wrote:
On Tue, Jan 13, 2026 at 10:59:49AM +0100, Markus Armbruster wrote:
Daniel P. Berrangé <berrange@redhat.com> writes:
There is a gotcha with qemu_log() usage in a threaded process. If fragments of a log message are output via qemu_log() it is possible for messages from two threads to get mixed up. To prevent this qemu_log_trylock() should be used, along with fprintf(f) calls.
This is a subtle problem that needs to be explained in the API docs to ensure correct usage.
Reported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
[...]
"Should normally" suggests there are exceptions.
"Should only" does not.
"Must" is a bit stronger still.
Which of the three do we want?
The "Should" usage was reflecting the reality that we have quite alot of code using qemu_log_trylock + qemu_log, instead of qemu_log_trylock + fprintf.
Yes.
I didn't feel it appropriate to use 'must' unless we explicitly make qemu_log() fail when used inside the scope of a qemu_log_trylock().
Fair.
So "Should normally" is the best fit
Actually specifically in the log.rs case, we have a greater constraint. The rust code for log_mask_ln will unconditionally add a newline to all messages. So this Rust method *must* only be usd for complete messages, regardless of what policy we have on the C qemu_log() call.
Got it. Suggest to consistently use "should normally" in the contracts where it is the best fit. Use "must" for the Rust method, and maybe mention it in the commit message (you decide).