[Qemu-devel] Make qemu_thread_create return a flag to indicate if it succeeded

[Qemu-devel] Make qemu_thread_create return a flag to indicate if it succeeded

[Achilles Benetopoulos]

I am interested in working on the BiteSized Task mentioned in the
subject line. However, I have a question: Since the current behaviour
of qemu_thread_create is to fail in the case of an error, then it
seems logical to make the caller exit (in the patched version) if the
return value of the call to qemu_thread_create indicates an error. Is
this desirable? If so, how detailed should the error messages reported
be? If not, then I'm guessing that the desired behaviour is a more
graceful handling of the error on a case-by-case basis?

Achilles

Re: [Qemu-devel] Make qemu_thread_create return a flag to indicate if it succeeded

[Alex Bennée]

Achilles Benetopoulos <abenetopoulos@gmail.com> writes:

> I am interested in working on the BiteSized Task mentioned in the
> subject line. However, I have a question: Since the current behaviour
> of qemu_thread_create is to fail in the case of an error, then it
> seems logical to make the caller exit (in the patched version) if the
> return value of the call to qemu_thread_create indicates an error. Is
> this desirable? If so, how detailed should the error messages reported
> be? If not, then I'm guessing that the desired behaviour is a more
> graceful handling of the error on a case-by-case basis?

It will depend on a case-by-case basis. For example failing to create
threads for a TCG vCPU don't really leave much for you to do expect
complain loudly and exit. I assume the more graceful handling is for
things like thread-pools where you can continue to run even without a
fully populated pool.

--
Alex Bennée

Re: [Qemu-devel] Make qemu_thread_create return a flag to indicate if it succeeded

[Dr. David Alan Gilbert]

* Alex Bennée (alex.bennee@linaro.org) wrote:
> 
> Achilles Benetopoulos <abenetopoulos@gmail.com> writes:
> 
> > I am interested in working on the BiteSized Task mentioned in the
> > subject line. However, I have a question: Since the current behaviour
> > of qemu_thread_create is to fail in the case of an error, then it
> > seems logical to make the caller exit (in the patched version) if the
> > return value of the call to qemu_thread_create indicates an error. Is
> > this desirable? If so, how detailed should the error messages reported
> > be? If not, then I'm guessing that the desired behaviour is a more
> > graceful handling of the error on a case-by-case basis?
> 
> It will depend on a case-by-case basis. For example failing to create
> threads for a TCG vCPU don't really leave much for you to do expect
> complain loudly and exit. I assume the more graceful handling is for
> things like thread-pools where you can continue to run even without a
> fully populated pool.

Or on migration we can fail the migration but still leave the guest
running in no worse state than it was before.

Dave

> --
> Alex Bennée
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] Make qemu_thread_create return a flag to indicate if it succeeded

[Daniel P. Berrange]

On Thu, Mar 16, 2017 at 06:55:47PM +0200, Achilles Benetopoulos wrote:
> I am interested in working on the BiteSized Task mentioned in the
> subject line. However, I have a question: Since the current behaviour
> of qemu_thread_create is to fail in the case of an error, then it
> seems logical to make the caller exit (in the patched version) if the
> return value of the call to qemu_thread_create indicates an error. Is
> this desirable? If so, how detailed should the error messages reported
> be? If not, then I'm guessing that the desired behaviour is a more
> graceful handling of the error on a case-by-case basis?

I imagine it would be a two stage conversion. First add an 'Error **errp'
parameter ot the qemu_thread_create() API which gets set on failure. Have
all the callers check this error & exit if set. This is the easy bit.

Second stage is to actually make the callers propagate the error back up
their call stack, so we can avoid exiting QEMU entirely in appropriate cases.
This takes a little more investigation to figure out optimal behaviour for
each of the callers

eg, if we tried to add an I/O thread to an existing running guest, we don't
want QEMU to exit. We just want the error reported back up to the monitor
so the mgmt app can handle it.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|