Re: [PATCH] osdep.h: Add doc comment for qemu_get_thread_id()

[Eric Blake <eblake@redhat.com>]

On 7/31/20 2:44 AM, Markus Armbruster wrote:

>>> Thread_id should be optional and thus not filled in if we
>>> can't provide a sensible value. Unfortunately we made it
>>> mandatory in QMP.
>>
>> Normally, converting a mandatory output value to optional is a
>> back-compatibility risk (we could break apps that depended on it being
>> present).  But if the only apps that depended on it being present are
>> compiled on Linux, where the member will actually be present, I think
>> that changing the schema to make it optional for non-Linux platforms
>> won't be a back-compatibility nightmare (but we will have to be
>> careful in our documentation).
> 
> Options for systems where don't know how to compute a system-wide thread
> ID:
> 
> 0. Return a bogus value: the PID.  This is the status quo.
> 
> 1. Return a more obviously bogus value: -1.  Semantic compatibility
>     break.  Should be harmless, because a QMP client relying on the
>     thread-id being the PID would be insane.
> 
> 2. Make thread-id optional, present iff we can compute a value.
> 
>     This is what we should have done, but we didn't, and now it's a
>     syntactic compatibility break.  Matters only if it actually breaks
>     QMP clients.  We believe the one we know shouldn't break.
> 
> Preferences?

I'm in favor of 2, but can easily live with 1 if we decide to be that 
much more conservative.  Tooling that can't handle a missing value is 
not going to fare any better with a value that is unusable because it is 
-1, but the important point is that I don't think we have a scenario 
with such tooling depending on the value (the tools that DO depend on 
the value are built on platforms where the value is usable).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org