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

From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	Markus Armbruster <armbru@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH] osdep.h: Add doc comment for qemu_get_thread_id()
Date: Fri, 31 Jul 2020 14:51:43 +0100	[thread overview]
Message-ID: <20200731135143.GG3641941@redhat.com> (raw)
In-Reply-To: <53b70f7f-1777-64e5-d80f-6af3d6c1252d@redhat.com>

On Fri, Jul 31, 2020 at 08:46:40AM -0500, Eric Blake wrote:
> 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).

I'm fine with (2) too. While technically a backcompat break, it won't
hurt us in the real world, and so is the pragmatic choice that gets us
to a long term better solution.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|