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

[Eric Blake]

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