Re: [Qemu-devel] [RFC] queue_work proposal

[Avi Kivity <avi@redhat.com>]

On 09/03/2009 03:52 AM, Glauber Costa wrote:
> Hi guys
>
> In this patch, I am attaching an early version of a new "on_vcpu" mechanism (after
> making it generic, I saw no reason to keep its name). It allows us to guarantee
> that a piece of code will be executed in a certain vcpu, indicated by a CPUState.
>
> I am sorry for the big patch, I just dumped what I had so we can have early directions.
> When it comes to submission state, I'll split it accordingly.
>
> As we discussed these days at qemu-devel, I am using pthread_set/get_specific for
> dealing with thread-local variables. Note that they are not used from signal handlers.
> A first optimization would be to use TLS variables where available.
>
> In vl.c, I am providing a version of queue_work for the IO-thread, and other for normal
> operation. The "normal" one should fix the problems Jan is having, since it does nothing
> more than just issuing the function we want to execute.
>
> The io-thread version is tested with both tcg and kvm, and works (to the extent they were
> working before, which in kvm case, is not much)
>    

on_vcpu() and queue_work() are fundamentally different (yes, I see the 
wait parameter, and I think there should be two separate functions for 
such different behaviours).

Why do we need queue_work() in the first place?

Is there a way to limit the queue size to prevent overflow?


-- 
error compiling committee.c: too many arguments to function