qemu-devel
[Top][All Lists]
Advanced

[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: Thu, 30 Jul 2020 11:24:51 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 7/30/20 10:59 AM, Daniel P. Berrangé wrote:

Well, I suspect that management-layer code currently has
gone for "assume we're always running on Linux" and was
written by people who knew they were getting a Linux tid...

Yes, on the libvirt side, the functionality that relies on thread_is is
only compiled on Linux. If someone wants to use it on other OS, they'll
have to provide an impl using their platforms equivalent of
sched_setaffinity and friends since none of this stuff is standardized
across OS.


The PID is quite unlikely to be "an OS-specific identifier of the
current thread".  Shouldn't we fail instead of lie when we don't know
how to compute the truth?

Yeah, I think the default codepath is pretty bogus too. Should
the QMP functions have a mechanism for saying "we don't know
a thread-id on this platform" ?

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).

--
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]