Hi Cedric, On Wed, 2007-01-31 at 16:28 +0100, Cedric Le Goater wrote: > Masahiko Takahashi wrote: > > > > I would like to post a small patch that implements pipe checkpoint > > and restart functionality. > > so do you have some test programs that uses it ? It would most > interesting to see how all fits together. My test program is only for debugging pipe without using namespace. So, I'm afraid it is not your interesting "all fits together" one. > It seems to me that we need to think about the whole framework of > file checkpoint and restart before anything else. sure pipes are > kinda a special case because they are created by pairs (just > like socketpair). > > but all files have things in common, they have an fd which requires > to be the same at restart. they can be shared between processes > to start with which needs to be optimized at checkpoint and taken > into account. they have flags, etc. > > then, some have pending data, like socket and pipes. > > did you start to work on such a framework ? This is not a kind of framework but my assumption here is to split an entity and descriptor sharing information. In checkpointing, first, saves the entity by its owner (as you mentioned above, special care is needed for pipe and socketpair since there might be a peer) and then saves its sharing information. Same in restoring. An entity is one of ordinary file, pipe, or socket (socketpair, UDP, TCP, and so on) including buffer (pending data), and its actual processing depends on its type. My first trial was pipe. Since restoring entity is issued by its owner process, PID isn't required in arguments. Sharing information requires PID as its argument because a file descriptor may be shared between processes. I didn't implement this because I didn't care pid namespace so far. Thanks, Masahiko.
