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

[Avi Kivity <avi@redhat.com>]

On 09/03/2009 02:15 PM, Glauber Costa wrote:
>
>> 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).
>>      
> Therefore, the name change. The exact on_vcpu behaviour, however, can be
> implemented ontop of queue_work().

Will there be any use for asynchronous queue_work()?

It's a dangerous API.

> Instead of doing that, I opted for using it
> implicitly inside kvm_vcpu_ioctl, to guarantee that vcpu ioctls will always run
> on the right thread context.

I think it's reasonable to demand that whoever calls kvm_vcpu_ioctl() 
know what they are doing (and they'll get surprising results if it 
switches threads implicitly).

> Looking at qemu-kvm, it seems that there are a couple
> of other functions that are not ioctls, and need on_vcpu semantics. Using them becomes
> a simple matter of doing:
>
>     queue_work(env, func, data, 1);
>
> I really don't see the big difference you point. They are both there to force a specific
> function to be executed in the right thread context.
>    

One of them is synchronous, meaning the data can live on stack and no 
special synchronization is needed, while the other is synchronous, 
meaning explicit memory management and end-of-work synchronization is 
needed.

>> Why do we need queue_work() in the first place?
>>      
> To force a function to be executed in the correct thread context.
> Why do we need on_vcpu in the first place?
>    

on_vcpu() is a subset of queue_work().  I meant, why to we need the 
extra functionality?

>> Is there a way to limit the queue size to prevent overflow?
>>      
> It can be, but it gets awkward. What do you do when you want a function needs to execute
> on another thread, but you can't? Block it? Refuse?
>    

What if the thread is busy?  You grow the queue to an unbounded size?

> We could pick one, but I see no need. The vast majority of work will never get queued,
> since we'll be in the right context already.
>    

A more powerful API comes with increased responsibilities.

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