Re: [Qemu-devel] [PATCH V17 07/10] libqblock: libqblock API design and type defines

[Stefan Hajnoczi]

On Tue, Feb 05, 2013 at 11:00:11PM +0800, Wenchao Xia wrote:
>   Adding pad for every public structure seems the easiest way now,
> I'll do that in next version.
> >Il 05/02/2013 13:39, Stefan Hajnoczi ha scritto:
> >>On Tue, Feb 05, 2013 at 10:56:09AM +0100, Paolo Bonzini wrote:
> >>>Il 01/02/2013 10:32, Stefan Hajnoczi ha scritto:
> >>>>>>What is the relationship between QBlockImage and its context?  Can I
> >>>>>>have two contexts A and B like this:
> >>>>>>
> >>>>>>qb_image_ref(ctx_a, &qbi);
> >>>>>>qb_image_unref(ctx_b, &qbi);
> >>>>>>
> >>>>>>Is this okay?
> >>>>>>
> >>>>>   it should be OK if block layer is thread safe in the future,
> >>>>>a thread should own a context. But caller may need to make sure
> >>>>>every context should call ref/unref as pairs.
> >>>>
> >>>>Hmm...I still don't understand the relationship between QBlockImage and
> >>>>a context.  Is it safe to use a QBlockImage with context B if it was
> >>>>created with context A?  This should be documented.
> >>>
> >>>No, it shouldn't.
> >>
> >>I guess you mean "It is not safe to use a QBlockImage with context B if
> >>it was created with context A" rather than "No, it shouldn't be
> >>documented"? :)
> >
> >Indeed. :)
> >
>   About the qbcontext, there are two choices:
> 1 discard of qbcontext, adding *error to get error message
> for every API. Need to confirm how to make it work
> with glib's aio-context.
> 2 keep qbcontext, every thread use it to store its thread
> specific data, such as errors, and it is easy to package
> glib's multi-thread contents inside.
>   Which way do you like better?

What about associating a QBlockImage with a context?  Then errors can be
stored and retrieved from the context, but the user doesn't need to pass
the context explicitly.

Stefan