[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 3/3] Add a 'name' parameter to qemu_thread_creat
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [PATCH 3/3] Add a 'name' parameter to qemu_thread_create |
Date: |
Tue, 28 Jan 2014 17:21:03 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11 |
On 01/28/14 17:12, Dr. David Alan Gilbert wrote:
> * Michael S. Tsirkin (address@hidden) wrote:
>> On Tue, Jan 28, 2014 at 03:20:39PM +0000, Dr. David Alan Gilbert (git) wrote:
>>> From: "Dr. David Alan Gilbert" <address@hidden>
>>>
>>> If enabled, set the thread name at creation (on GNU systems with
>>> pthread_set_np)
>>> Fix up all the callers with a thread name
>>>
>>> Signed-off-by: Dr. David Alan Gilbert <address@hidden>
>>
>> Thanks for the patch.
>>
>> It worries me that tool might start assuming specific
>> thread names - this effectively becomes part of
>> management interface.
>>
>> We avoided this in the past except for VCPU threads -
>> in particular we only expose thread id for VCPU threads.
>> How about some generic name for non-VCPU threads
>> to avoid this issue?
>
> Since I'm doing migration development, restriction to VCPU
> threads doesn't help me much.
I'm not doing migration development, but I agree that the feature is
only really useful if *all* threads have names. (IOW when it completely
saves the developer the work to figure out which thread is which.)
> Putting big scary warnings somewhere (where?) to say that
> the names aren't guaranteed is all I can think of.
> (I did put that warning in the cover letter).
>
> I guess I could change the option name to debug-threads
> to make it clear it's for debug.
>
>> Also - should we put VCPU # in the thread name?
>
> Yeh that's something I could add.
Would be very useful.
Thanks
Laszlo