Re: [Qemu-devel] [PATCH 1/3] Introduce threadlets

[Venkateswararao Jujjuri (JV)]

On 10/14/2010 9:16 AM, Avi Kivity wrote:
>  On 10/14/2010 11:15 AM, Stefan Hajnoczi wrote:
>> I forgot to add that the semantics of cancellation make it difficult
>> to write correct user code.  Every cancellation user needs to add
>> extra synchronization after the cancel call to handle the case where
>> the work is currently executing.
>>
>> This seems tricky to me and I suspect code using this interface will
>> be buggy.  How about the following?
>> 1. Add a return value indicating that the work is currently executing
>> (this still requires the caller to add extra synchronization but is at
>> least explicit) versus work is no longer on the list.

Current semantics is .. if not on the list it is currently executing or we are
done with it.
How do we differentiate between those two? Do we need any other state?
>> 2. Add a flag to block until the work has been cancelled or completed.
>>   This is useful to callers who are allowed to block.
> 
> Blocking is somewhat against the spirit of the thing, no?  While I agree that
> the current cancel API is hard to use correctly, blocking defeats the purpose 
> of
> the API.
> 
Are you proposing to add additional state in the return
(canceled/running/not-canceled)
and leave the synchronization part to the user?
i.e not to provide any additional interface for the user to wait
for the scheduled work to finish? Just trying to understand.

Thanks,
JV