qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH V3 1/3] qemu: Add qemu-wrappers for pthread_


From: Gautham R Shenoy
Subject: Re: [Qemu-devel] Re: [PATCH V3 1/3] qemu: Add qemu-wrappers for pthread_attr_t
Date: Thu, 10 Jun 2010 16:42:50 +0530
User-agent: Mutt/1.5.17 (2007-11-01)

On Fri, Jun 04, 2010 at 03:19:34PM +0200, Corentin Chary wrote:
> On Fri, Jun 4, 2010 at 3:07 PM, Anthony Liguori <address@hidden> wrote:
> > On 06/03/2010 07:31 AM, Paolo Bonzini wrote:
> >>
> >> On 06/03/2010 10:56 AM, Gautham R Shenoy wrote:
> >>>
> >>> Add qemu wrappers for pthread_attr_t handling.
> >>
> >> The point of these wrappers AFAIU is not only to add error_exit, but also
> >> to be portable to Windows in the future.  Is it necessary to create the
> >> threads as detached?  If you set queue->min_threads to zero all threads
> >> should exit as soon as they finish their work (which is better than exiting
> >> immediately).
> >
> > This is historical because the code was largely inspired by glibc's
> > implementation of posix-aio.  It doesn't need to be detached and since
> > Corentin wants to be able to join a worker, it makes sense to just avoid
> > detaching and pay the overhead of making the threads joinable.
> >
> > Regards,
> >
> > Anthony Liguori
>

Sorry for the late response. I had been away for the last few days.

> Actually, I want to know if the queue is empty and if no job are
> currently being processed: all worker are idle or stopped.

In other words, you just want to know if the already submitted jobs
have gotten over or not so that you could probably destroy the queue.

The subsystem using the queueing infrastructure is responsible for providing
the guarantee that no new job would be submitted while/after making a call
query the idleness of the queue.

If this understanding is correct, we might want to have a
qemu_async_barrier() implementation which waits for all the threads
finish processing the queued jobs, and destroy themselves.

>I don't really need pthread_join() for that, since worker can be idle (we
> don't want to always start and stop the thread :) ).

-- 
Thanks and Regards
gautham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]