On 11/24/2010 02:15 AM, Anthony Liguori wrote:
Is it signal safe?
Yes, at heart it is just a somewhat more expensive access to
pthread_self()->some_array[key].
BTW, this is all only theoretical. This is in the KVM io thread code
which is already highly unportable.
True, and newer versio
On 11/23/2010 05:43 PM, Paolo Bonzini wrote:
On 11/23/2010 10:46 PM, Anthony Liguori wrote:
+static __thread int sigusr1_wfd;
While OpenBSD finally updated the default compiler to 4.2.1 from 3.x
series, thread local storage is still not supported:
Hrm, is there a portable way to do this (dist
On 11/23/2010 10:46 PM, Anthony Liguori wrote:
+static __thread int sigusr1_wfd;
While OpenBSD finally updated the default compiler to 4.2.1 from 3.x
series, thread local storage is still not supported:
Hrm, is there a portable way to do this (distinguish a signal on a
particular thread)?
Yo
On 11/23/2010 01:35 PM, Blue Swirl wrote:
On Tue, Nov 23, 2010 at 4:49 PM, Anthony Liguori wrote:
qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of teaching
them to respond to these signals (which cannot be trapped), use SIGUSR1 to
approximate the behavior of SIGSTOP/SIGC
On Tue, Nov 23, 2010 at 4:49 PM, Anthony Liguori wrote:
> qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of teaching
> them to respond to these signals (which cannot be trapped), use SIGUSR1 to
> approximate the behavior of SIGSTOP/SIGCONT.
>
> The purpose of this is to implemen
