+ 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.
I think Anthony answered this one.
I think he said that the code has been changed so I am right? :)
+/**
+ * flush_threadlet_queue: Wait till completion of all the submitted tasks
+ * @queue: Queue containing the tasks we're waiting on.
+ */
+void flush_threadlet_queue(ThreadletQueue *queue)
+{
+ qemu_mutex_lock(&queue->lock);
+ queue->exit = 1;
+
+ qemu_barrier_init(&queue->barr, queue->cur_threads + 1);
+ qemu_mutex_unlock(&queue->lock);
+
+ qemu_barrier_wait(&queue->barr);
Can be implemented just as well with queue->cond and a loop waiting for
queue->cur_threads == 0. This would remove the need to implement barriers
in qemu-threads (especially for Win32). Anyway whoever will contribute
Win32 qemu-threads can do it, since it's not hard.
That was the other option I had considered before going for barriers,
for no particular reason. Now, considering that barriers are not
welcome, I will implement this method.
I guess we decided flush isn't really useful at all. Might as well
leave it out of v5 and implement it later, so the barrier and
complicated exit condition are now unnecessary.
Thanks,
Paolo
