On Mon, Dec 11, 2017 at 07:51:43AM -0600, Eric Blake wrote:
> On 12/11/2017 04:16 AM, Stefan Hajnoczi wrote:
>
> >>> I don't understand the need for the qemu_lock_guard_is_taken(&name)
> >>> condition, why not do the following?
> >>>
> >>> for (QEMU_LOCK_GUARD(type, name, lock);
> >>>;
>
On 12/11/2017 04:16 AM, Stefan Hajnoczi wrote:
>>> I don't understand the need for the qemu_lock_guard_is_taken(&name)
>>> condition, why not do the following?
>>>
>>> for (QEMU_LOCK_GUARD(type, name, lock);
>>>;
>>>qemu_lock_guard_unlock(&name))
>>
>> Because that would be an in
On Fri, Dec 08, 2017 at 06:56:12PM +0100, Paolo Bonzini wrote:
> On 08/12/2017 16:30, Stefan Hajnoczi wrote:
> > On Fri, Dec 08, 2017 at 11:55:50AM +0100, Paolo Bonzini wrote:
> >
> > The implementation is somewhat complex. Please structure the header
> > file so the public interfaces are clear a
On 12/08/2017 11:56 AM, Paolo Bonzini wrote:
>>> +typedef void QemuLockGuardFunc(void *);
>>> +typedef struct QemuLockGuard {
>>> +QemuLockGuardFunc *p_lock_fn, *p_unlock_fn;
>>> +void *lock;
>>> +int locked;
>>
>> bool?
>
> Yes.
>
>>> +#define QEMU_WITH_LOCK(type, name, lock)
On 08/12/2017 16:30, Stefan Hajnoczi wrote:
> On Fri, Dec 08, 2017 at 11:55:50AM +0100, Paolo Bonzini wrote:
>
> The implementation is somewhat complex. Please structure the header
> file so the public interfaces are clear and documented. Move the
> implementation out of the way and mark it priv
On Fri, Dec 08, 2017 at 11:55:50AM +0100, Paolo Bonzini wrote:
The implementation is somewhat complex. Please structure the header
file so the public interfaces are clear and documented. Move the
implementation out of the way and mark it private. That will make it
easier for someone to figure o
Signed-off-by: Paolo Bonzini
---
include/qemu/coroutine.h | 4 ++
include/qemu/lock-guard.h | 99 +++
include/qemu/thread.h | 7
util/Makefile.objs| 1 +
util/qemu-thread.c| 17
5 files changed, 128 insertions(+)
c
