[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [PATCH] osdep.h: Add doc comment for qemu_get_thread_id()
Date: Fri, 31 Jul 2020 08:46:40 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]