Daniel P. Berrangé <[email protected]> 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é <[email protected]> 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 <[email protected]> >> > > Signed-off-by: Daniel P. Berrangé <[email protected]>
[...] >> > "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).
