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