Quoting Dwight Engen (dwight.en...@oracle.com):
> On Fri, 24 May 2013 08:09:21 -0500
> > -sem_t *lxc_newlock(const char *name)
> > +struct lxc_lock *lxc_newlock(const char *lxcpath, const char *name)
> > {
> > - char *lname;
> > - sem_t *lock;
> > + struct lxc_lock *l;
> > + int ret = pthread_mutex_lock(&thread_mutex);
>
> What is taking this lock here protecting? It looks like its all thread
> local allocations? Maybe I'm missing something but I'm confused why we
> need the pthread mutex around any of these locking primitives. Won't
> this potentially cause a threadA trying to operate on unlocked
> container1 to block when threadB is in a critical section with
> unrelated container2?
Yeah, we need it around the fopen() and flock(), you're right
we shouldn't need it here.
-serge
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
