Re: [PATCH][RFC] Use pipe() to simulate signalfd()

[Anthony Liguori <aliguori@us.ibm.com>]

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