Quoting Stéphane Graber (stgra...@ubuntu.com): > On 04/10/2013 06:49 AM, Serge Hallyn wrote: > > Quoting S.Çağlar Onur (cag...@10ur.org): > >> Hi Serge, > >> > >> On Tue, Apr 9, 2013 at 4:47 PM, Serge Hallyn > >> <serge.hal...@ubuntu.com>wrote: > >> > >>> All right you made me finally take a closer look at the monitor code > >>> (which I'd been avoiding). It's much simpler than I'd imagined. So > >>> here are the challenges: > >>> > >>> 1. lxc-monitor should be able to watch 'all containers' (at least under > >>> a given lxcpath). That is actually the strong reason to object to your > >>> patch. > >>> > >> > >> Ah, that makes sense. > >> > >> > >>> 2. we don't want to force any long-running daemon to run as the monitor. > >>> 3. we want to allow multiple containers to send state change info > >>> to multiple simulataneous lxc-monitor and lxc-wait listeners. > >>> > >>> Now I can think of some whacky solutions, but are there any simple ones > >>> I'm overlooking? > >> > >> > >> I'm not sure what is your whacky solution but if I'm not missing something > >> this sounds like multicast :) I'm sorry for my ignorance but did multicast > >> unix sockets patch set find its way into upstream kernel? > > > > It looks to be a tough sell to the networking maintainer :) > > > > http://lkml.org/lkml/2012/2/28/369 > > > > -serge > > So my basic plan for the monitor was to allow multiple connections to > the socket with the easiest way of doing that being to use > multithreading, spawning a thread for each connection.
Who's doing this thread-spawning? You're assuming a long-running daemon, which violates #2 above. If we're ok with that, then that definately simplifies things. > There are other ways to deal with non-blocking reads on multiple sockets > (basically an infinite loop of accept/read without threading) which we > may want to look into if we want to avoid threading. > > > Now, having that information broadcast may have its value, but I think > in LXC itself, we should probably stick to unicast and leave > broadcasting this to an external piece of software which would use our > API to monitor all the containers and provide some kind of bridge to DBus. > The current obvious "multi-casty" thing on the Linux desktop is DBus and > while we could theoretically use it as a replacement for our current > unix socket, I don't really think we want to bring it as a dependency > for LXC. > > > -- > Stéphane Graber > Ubuntu developer > http://www.ubuntu.com > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Lxc-devel mailing list > Lxc-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
