Thanks Çağlar! I'll look into those things.
On Thu, 18 Apr 2013 15:08:19 -0400
S.Çağlar Onur wrote:
> Hi,
>
> I think I got it why, most likely recvfrom gets an EINTR there like
> select.
>
> int lxc_monitor_read_timeout(int fd, struct lxc_msg *msglxc, int
> timeout) {
> struct sockadd
On Thu, 18 Apr 2013 13:48:25 -0500
Serge Hallyn wrote:
> Quoting Dwight Engen (dwight.en...@oracle.com):
> > After the recent discussions on the lxc monitor, I took a closer
> > look at it. It seems like Serge was resigned to having some sort of
> > daemon as having multicast unix domain supporte
Quoting Dwight Engen (dwight.en...@oracle.com):
> After the recent discussions on the lxc monitor, I took a closer look at
> it. It seems like Serge was resigned to having some sort of daemon as
> having multicast unix domain supported by the kernel is not going to
> happen any time soon, and doing
On Thu, 18 Apr 2013 14:22:08 -0400
S.Çağlar Onur wrote:
> Hey Dwight,
>
> This sounds great, I'll give it a try ASAP. In the meantime ,if you
> want to test it yourself, you can grab go bindings from github via
> "go get github.com/caglar10ur/lxc" but please keep in your mind that
> you need my
After the recent discussions on the lxc monitor, I took a closer look at
it. It seems like Serge was resigned to having some sort of daemon as
having multicast unix domain supported by the kernel is not going to
happen any time soon, and doing it over loopback has some
complications too.
Initially
