On 04/10/2013 06:43 PM, Serge Hallyn wrote: > 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.
lxc-start is already a long-running "daemon" which listens on the unix socket, all we'd need is to have it spawn a new thread for each connection instead of processing the monitor command itself. >> 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 > -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
