[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/3] colo-compare: serialize compare thread's in

From: Hailiang Zhang
Subject: Re: [Qemu-devel] [PATCH 1/3] colo-compare: serialize compare thread's initialization with main thread
Date: Wed, 26 Apr 2017 15:51:28 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 2017/4/25 19:33, Jason Wang wrote:

On 2017年04月25日 17:59, Hailiang Zhang wrote:
On 2017/4/25 16:41, Jason Wang wrote:
On 2017年04月24日 14:03, Hailiang Zhang wrote:
On 2017/4/24 12:10, Jason Wang wrote:
On 2017年04月20日 15:46, zhanghailiang wrote:
We call qemu_chr_fe_set_handlers() in colo-compare thread, it is used
to detach watched fd from default main context, so it has chance to
handle the same watched fd with main thread concurrently, which will
trigger an error report:
"qemu-char.c:918: io_watch_poll_finalize: Assertion `iwp->src ==
((void *)0)' failed."
Anyway to prevent fd from being handled by main thread before creating
colo thread? Using semaphore seems not elegant.
So how about calling qemu_mutex_lock_iothread() before
qemu_chr_fe_set_handlers() ?
Looks better, but I needs more information e.g how main thread can
touch it?
Hmm, this happened quite occasionally, and we didn't catch the first
place (backtrace)
of removing fd from been watched, but  from the codes logic, we found
there should
be such possible cases:
tcp_chr_write (Or tcp_chr_read/tcp_chr_sync_read/chr_disconnect)
  ->tcp_chr_disconnect (Or char_socket_finalize)
       -> remove_fd_in_watch(chr);

Anyway, it needs the protection from been freed twice.

Still a little bit confused. The question is how could main thread still
call tcp_chr_write or other in the above case?

The 'char_socekt_finalize' ? Hmm, I'd better to reproduce it again to get the 
time of removing the fd been watched...





reply via email to

[Prev in Thread] Current Thread [Next in Thread]