Quoting Christian Seiler (christ...@iwakd.de): > 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.
Oooh, gotcha. That just may be our solution! At that point the only potential problem would be reaaaaaaaly-long container names :) -serge ------------------------------------------------------------------------------ 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
