On Wed, Jun 16, 2010 at 5:20 PM, Anthony Liguori
<aligu...@linux.vnet.ibm.com> wrote:
> On 06/16/2010 09:52 AM, Paolo Bonzini wrote:
>>
>> On 06/16/2010 04:38 PM, Anthony Liguori wrote:
>>>
>>> On 06/16/2010 09:29 AM, Paolo Bonzini wrote:
>>>>
>>>> On 06/16/2010 04:22 PM, Jamie Lokier wrote:
>>>>>
>>>>> Paolo Bonzini wrote:
>>>>>>
>>>>>> These should be (at least for now) block-obj-$(CONFIG_POSIX).
>>>>>>
>>>>>>> + while (QTAILQ_EMPTY(&(queue->request_list))&&
>>>>>>> + (ret != ETIMEDOUT)) {
>>>>>>> + ret = qemu_cond_timedwait(&(queue->cond),
>>>>>>> + &(queue->lock), 10*100000);
>>>>>>> + }
>>>>>>
>>>>>> Using qemu_cond_timedwait is a hack for not properly broadcasting the
>>>>>> condvar in flush_threadlet_queue.
>>>>>
>>>>> Are you sure? It looks like it also expires idle threads after a
>>>>> fixed amount of idle time.
>>>>
>>>> Unnecessary idle threads are immediately expired as soon as the
>>>> threadlet exits if ncecessary, since here
>>>
>>> If a threadlet is waiting to consume more work, unless we do a
>>> pthread_cancel (I dislike cancellation) it will keep waiting until it
>>> gets more work (which would mean it's not actually idle)...
>>
>> Agreed---no cancellation, please.
>>
>> BTW it's obviously okay with signaling the condition when a threadlet is
>> submitted. But when something affects all queue's workers
>> (flush_threadlet_queue) you want a broadcast and using expiration as a
>> substitute is fishy.
>
> IMHO, there shouldn't be a need for flush_threadlet_queue. It doesn't look
> used in the aio conversion and if virtio-9p needs it, I suspect something is
> wrong.
>
I would need something like flush_threadlet_queue for the vnc server.
I need it in
vnc_disconnect(), vnc_dpy_resize() and vnc_dpy_cpy() so wait (and/or
abort) current
encoding jobs.
--
Corentin Chary
http://xf.iksaif.net
