Quoting Dwight Engen (dwight.en...@oracle.com):
> I think the names you've got are fine (don't really have a better
> idea), I do think its good to name locks by what they cover. Its a bit
> tricky here because one is a process (and thread) lock and the other
> is just a thread lock and it would be nice to convey that somehow.
>
> In thinking about this a bit, the memlock and the pthread mutex are
> really the same (a thread lock), they just cover different regions (ie.
Agreed, so we should have 3 lock functions. Actually, for clarity the
two could be lxc_container member functions, so there would be:
task_lock(); // or process_lock()
c->mem_lock(c);
c->disk_lock(c);
> in memory struct lxc_container vs process data). The sem_t could just
> as easily be a pthread_mutex_t or vice versa, I think they're built on
Agreed, I'd like to make that change - after other things settle down.
> the same primitives in glibc. One reason for potentially switching the
> sem to a pthread mutex is if we decide to expose the locking in an api
> we'll almost certainly want to use robust locks.
>
> I wonder if something like this is any clearer?
>
> extern int lxclock(struct lxc_container *c, int type);
>
> lxclock(c, LXC_LOCK_DISK); -> flock c->slock
> lxclock(c, LXC_LOCK_MEM); -> pthread/sem lock c->privlock
> lxclock(NULL, LXC_LOCK_PROC); -> pthread/sem lock whole process
Right now I feel like it'll be clearer to have different function
names for each type of lock - mainly because I think it takes less
visual/mental processesing while looking at a chunk of code to
know which lock is in use. But I may be thinking wrongly...
> I don't know if this is any clearer or not, but I do think its a bit
> bad to have thread_mutex exposed and not wrapped.
>
> > > I think I'll have a few more comments/questions after I read
> > > through the rest of the patch.
> >
> > Excellent, thanks.
> >
> > -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
