On Sun, 2008-06-22 at 17:40 -0400, Oren Laadan wrote: > One issue with this approach is that the operation (checkpoint) becomes > non-transparent to the "checkpointee"s: re-writing the data back into > the pipe/fifo may generate a SIGIO at the read-side of the pipe/fifo, or > an inotify event on the inode, without a real reason. This may confuse > the application if its logic relies on "normal" behavior. Yeah, I guess this is true, somewhat. But, for something expecting to read from a pipe, they'll get a SIGIO when the data is first written. If the signal has not yet been delivered then we're fine because we won't generate *another* one. If they've already received the signal and left the data in the pipe, what harm does another SIGIO do? The kernel is free to give the app a SIGIO for every single byte stuck in the pipe, right? So, what difference does any number of SIGIOs make when there's data sitting in the pipe unread? As for inotify, yeah that might be an actual issue. It's probably good to note this potential issue, and to watch for anyone doing inotifies on a pipe fd when we get to checkpointing inotify. Overall, seems like an awfully minor issue to me. -- Dave _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
