Greg Kurz writes:
> On Fri, 11 Jan 2019 16:41:41 +0100
> Paolo Bonzini wrote:
>
>> On 11/01/19 16:28, Alex Bennée wrote:
>> >> Why not g_usleep? It already does a while loop around nanosleep (which
>> >> returns the remaining time in the wait, like select but unlike sleep and
>> >> poll).
>>
On Fri, Jan 11, 2019 at 04:06:54PM +, Alex Bennée wrote:
>
> Paolo Bonzini writes:
>
> > On 11/01/19 16:28, Alex Bennée wrote:
> >>> Why not g_usleep? It already does a while loop around nanosleep (which
> >>> returns the remaining time in the wait, like select but unlike sleep and
> >>> po
On Fri, 11 Jan 2019 16:41:41 +0100
Paolo Bonzini wrote:
> On 11/01/19 16:28, Alex Bennée wrote:
> >> Why not g_usleep? It already does a while loop around nanosleep (which
> >> returns the remaining time in the wait, like select but unlike sleep and
> >> poll).
> > Yeah I'm testing that now. H
Paolo Bonzini writes:
> On 11/01/19 16:28, Alex Bennée wrote:
>>> Why not g_usleep? It already does a while loop around nanosleep (which
>>> returns the remaining time in the wait, like select but unlike sleep and
>>> poll).
>> Yeah I'm testing that now. However I have managed to trigger:
>>
>
Paolo Bonzini writes:
> On 11/01/19 16:28, Alex Bennée wrote:
>>> Why not g_usleep? It already does a while loop around nanosleep (which
>>> returns the remaining time in the wait, like select but unlike sleep and
>>> poll).
>> Yeah I'm testing that now. However I have managed to trigger:
>>
>
On 11/01/19 16:28, Alex Bennée wrote:
>> Why not g_usleep? It already does a while loop around nanosleep (which
>> returns the remaining time in the wait, like select but unlike sleep and
>> poll).
> Yeah I'm testing that now. However I have managed to trigger:
>
> ERROR:tests/test-qht-par.c:20
Paolo Bonzini writes:
> On 11/01/19 15:38, Alex Bennée wrote:
>> Relying on sleep to always return having slept isn't safe as a signal
>> may have occurred. If signals are constantly incoming the program will
>> never reach it's termination condition. This is believed to be the
>> mechanism cau
On 11/01/19 15:38, Alex Bennée wrote:
> Relying on sleep to always return having slept isn't safe as a signal
> may have occurred. If signals are constantly incoming the program will
> never reach it's termination condition. This is believed to be the
> mechanism causing time outs for qht-test in T
Relying on sleep to always return having slept isn't safe as a signal
may have occurred. If signals are constantly incoming the program will
never reach it's termination condition. This is believed to be the
mechanism causing time outs for qht-test in Travis.
Instead we use a g_timer to determine
