Thanks, applied.
On Sat, Jul 9, 2011 at 5:33 AM, Alexandre Raymond wrote:
> ping?
>
> On Wed, Jun 15, 2011 at 10:11 AM, Alexandre Raymond wrote:
>> Hi Jan,
>>
>>> Why? Ahh, because of qemu_cpu_kick_self: raise(SIG_IPI)! That should
>>> generate a per-process SIG_IPI. And that may not only affect
ping?
On Wed, Jun 15, 2011 at 10:11 AM, Alexandre Raymond wrote:
> Hi Jan,
>
>> Why? Ahh, because of qemu_cpu_kick_self: raise(SIG_IPI)! That should
>> generate a per-process SIG_IPI. And that may not only affect Darwin.
>> Looks good.
>
> Actually, with io-thread enabled, it goes through qemu_cp
Hi Jan,
> Why? Ahh, because of qemu_cpu_kick_self: raise(SIG_IPI)! That should
> generate a per-process SIG_IPI. And that may not only affect Darwin.
> Looks good.
Actually, with io-thread enabled, it goes through qemu_cpu_kick_self()
-> qemu_cpu_kick_thread() -> pthread_kill(..., SIG_IPI).
I th
On 2011-06-15 07:20, Alexandre Raymond wrote:
> Both the signal thread (via sigwait()) and the cpu thread (via
> a normal signal handler) were attempting to catch SIG_IPI.
Why? Ahh, because of qemu_cpu_kick_self: raise(SIG_IPI)! That should
generate a per-process SIG_IPI. And that may not only aff
Both the signal thread (via sigwait()) and the cpu thread (via
a normal signal handler) were attempting to catch SIG_IPI.
This resulted in random freezes under Darwin.
This patch separates SIG_IPI from the rest of the signals handled
by the signal thread, because it is independently caught by the
