[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH] simpletrace: Thread-safe tracing
From: |
Stefan Hajnoczi |
Subject: |
[Qemu-devel] Re: [PATCH] simpletrace: Thread-safe tracing |
Date: |
Mon, 28 Feb 2011 09:35:51 +0000 |
On Sun, Feb 27, 2011 at 6:16 PM, Paolo Bonzini <address@hidden> wrote:
> On 02/27/2011 06:02 PM, Stefan Hajnoczi wrote:
>>
>> On Sun, Feb 27, 2011 at 3:13 PM, Paolo Bonzini<address@hidden>
>> wrote:
>>>
>>> On 02/27/2011 03:58 PM, Stefan Hajnoczi wrote:
>>>>
>>>> + * Trace records are written out by a dedicated thread. The thread
>>>> waits
>>>> for
>>>> + * records to become available, writes them out, and then waits again.
>>>> + */
>>>> +static pthread_mutex_t trace_lock = PTHREAD_MUTEX_INITIALIZER;
>>>> +static pthread_cond_t trace_available_cond = PTHREAD_COND_INITIALIZER;
>>>> +static pthread_cond_t trace_empty_cond = PTHREAD_COND_INITIALIZER;
>>>> +static bool trace_available;
>>>> +static bool trace_writeout_enabled;
>>>
>>> Please use QemuThread.
>>
>> The tracing code itself should use avoid core QEMU code. Otherwise we
>> can't trace QemuThread - we'd have an infinite loop.
>
> Hmm, right... they'll use stdio to trace Win32 then... :) I was actually
> thinking more of the code duplication.
>
> But do you really need tracing at such a low level? I'd expect tracing
> wrappers like qemu_lock_mutex_iothread, not mutexes in general.
We can get away with it for some codepaths but it adds new constraints
that are hard to check against. For example, simpletrace uses
get_clock() but we need to limit ourselves as much as possible. If
that function calls any other core QEMU code like qemu_malloc(), then
we risk infinite recursion because qemu_malloc() has a useful trace
event.
Stefan