[Qemu-devel] Re: [PATCH] simpletrace: Thread-safe tracing

[Stefan Hajnoczi]

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