Hi Serge, >> Only problem: it's not thread-safe... And in contrast to openat() or the > > We could just do process_lock() around the whole shebang if we had to. > > But I can't think offhand of any reason why we'd ever need to go from > the socketname back to the lxcpath, so using md5sum really shouldn't > have any downsides.
One downside: it's less clear what container this is now for, when looking through /run. On the other hand, I don't really care that much about this, I just wanted to throw in how one can in principle get around the 108 byte limit - not whether that's necessarily very practical. >> One doesn't even need socket passing for this, since the socket can be > > socket passing I'd understand, and that could be a neat solution. But I > don't understand why the above would work. Since the pids had forked, > the fd numbered r would be meaningless to the original task, wouldn't > it? I must be missing something cool, though. No, r is the return code, the fd is always passed from parent to child (implicitly via fork), the child never passes anything back. The real trick behind the example I gave was that after fork() they are two different file descriptors, but still point to the same socket. And bind() doesn't operate on file descriptors, but rather on sockets. So anything the child process does to the socket (except close()) will have an effect on the parent process. -- Christian ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
