From owner-freebsd-fs Mon Jul 8 11:49:16 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA29450 for fs-outgoing; Mon, 8 Jul 1996 11:49:16 -0700 (PDT) Received: from baygate.bayarea.net (baygate.bayarea.net [204.71.212.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA29442 for ; Mon, 8 Jul 1996 11:49:14 -0700 (PDT) Received: (from mcnab@localhost) by baygate.bayarea.net (8.6.9/8.6.9) id LAA27246; Mon, 8 Jul 1996 11:42:51 -0700 Date: Mon, 8 Jul 1996 11:42:51 -0700 From: David McNab Message-Id: <199607081842.LAA27246@baygate.bayarea.net> To: robsch@robkaos.ruhr.de CC: freebsd-fs@freebsd.org In-reply-to: (robsch@robkaos.ruhr.de) Subject: Re: procfs Reply-to: David McNab Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Robert wrote: |Is it possible to freeze the current status of a process and |restart it at a later time so that it begins execution at |the point where it was frozen? You can suspend it, which means it won't eat any CPU time and can be easily paged out (won't consume any memory -- well, hardly any). But this won't be persistent across boots. If you want real checkpointing -- the kernel writes the executable and relevant context to a file and can later restart it -- then the only UNIX OS I'm familiar with that provides it, albeit in a slightly limited way, is UNICOS, Cray's UNIX. The hardware overhead's a bitch, though :^). It's a hard problem. There's lots of state scattered throughout the "system" that's hard to record and regenerate. It's especially hard if you are doing any networking, because then you have state in foreign address spaces. Most people seem to end up writing their number cruncher so that it periodically hits a "sync point" where they can easily checkpoint it themselves. -- Dave McNab