Messages in this thread | | | Subject | Re: Remote fork() and Parallel Programming | From | Andi Kleen <> | Date | 13 Jun 1998 11:09:01 +0200 |
| |
ralf@uni-koblenz.de writes:
> On Fri, Jun 12, 1998 at 10:21:52PM +0200, Lars Marowsky-Brée wrote: > > > On 1998-06-12T11:12:24, > > Larry McVoy <lm@bitmover.com> said: > > > > > : a process, you have to snapshot all related processes and the state of > > > : the kernel. It's a much better idea to have general persistency and take > > > : periodic system-wide snapshots. > > > > > > Yup. But throw a cluster into the mix and think about saving the state > > > of all those sockets. It's doable, just a pain in the butt. > > > > I am dreaming of doing an "atomic" cp /proc/pid/<> newhost:/proc/ *g* > > > > Seriously: Shouldn't be all information relating to a process and it's > > resource reside in /proc? This might be the first step to get process > > migration going, since then you could implement a clean interface. > > > > (You can implement this using other tricks, but using the proc fs has a > > certain "clean" and consistent appeal to me) > > It seems a lot of people hasn't understood that moving a process is > *far* more than just it's resources. It's less the silver bullet that > many people dream of than more the dragon hiding between the cluster's > back. > > Think of issues like a filepointer for a file which has grown since the > process snapshot was taken / started to be moved. Assume it was pointing > to the last byte and the file has grown. So now, where to position the > file when relaunching the process?
I think that's a bad example, because even non-migrating processes have to handle this case (because Linux is multi-process) and in Linux O_APPEND is handled in the low level filesystem atomically anyways.
If they don't want the file modified under them they should use flock().
-Andi
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |