Marcelo Tosatti wrote: > Problem is if the IO thread _receives_ SIGIPI instead of some vcpu > thread. > > So there is potential harm in not blocking it. >
Hrm, aren't SIG_IPIs delivered to a particular thread-id though? When would the IO thread receive a SIG_IPI? >>> What is the reason for this loop instead of a straight read? >>> >>> Its alright to be interrupted by a signal. >>> >>> >> Just general habit with QEMU. >> > > Please don't :-) > I don't see the harm. In fact, I think it's more correct. Otherwise, we have to wait for another invocation of the fd callback. >>>> - kvm_eat_signal(&io_signal_table, NULL, 1000); >>>> pthread_mutex_lock(&qemu_mutex); >>>> - cpu_single_env = NULL; >>>> - main_loop_wait(0); >>>> + main_loop_wait(10); >>>> >>>> >>> Increase that 1000 or something. Will make it easier to spot bugs. >>> >>> >> I have actually and it does introduce some bugs. I'm not entirely clear >> what is causing them though. >> > > Should indicate that some event previously delivered through signals and > received by sigtimedwait is not waking up the IO thread. > I'll take a look and see. I'm having time keeping issues in the guest so it's hard to tell what problems are caused by the IO thread verses time. Regards, Anthony Liguori ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
