[lxc-devel] [PATCH 1/1] locking: update per Dwight's comment

[Serge Hallyn]

Quoting Dwight Engen (dwight.engen at oracle.com):
> On Fri, 24 May 2013 16:09:59 -0500
> Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> 
> > ( These are pushed to github.com/hallyn/lxc branch
> > lxclock-flock.rebase )
> > 
> > Create three pairs of functions:
> > 	int process_lock(void);
> > 	void process_unlock(void);
> > 	int container_mem_lock(struct lxc_container *c)
> > 	void container_mem_unlock(struct lxc_container *c)
> > 	int container_disk_lock(struct lxc_container *c);
> > 	void container_disk_unlock(struct lxc_container *c);
> > 
> > and use those in lxccontainer.c
> > 
> > process_lock() is to protect the process state among multiple threads.
> > container_mem_lock() is to protect a struct container among multiple
> > threads.  container_disk_lock is to protect a container on disk.
> > 
> > Also remove the lock in lxcapi_init_pid() as Dwight suggested.
> > 
> > Fix a typo (s/container/contain) spotted by Dwight.
> > 
> > More locking fixes are needed, but let's first the the fundamentals
> > right.  How close does this get us?
> 
> Looks good to me, much cleaner in lxccontainer.c, nice! Minor question:
> can lxclock() and lxcunlock() be made static now?

Yup, I'll add that.

The one other thing we still need before create can move into the api is
the $lxcpath/$container/partial file.  I"ll have lxcapi_create() create
that file at start, delete it at end, and have lxcapi_start() and
lxc_container_new() delete what they find on disk if that file is still
there.  (That may be too rash, but I don't think it is.)

> Acked-by: Dwight Engen <dwight.engen at oracle.com>