From owner-freebsd-hackers Sun Mar 12 15:20:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 7349037BBE4 for ; Sun, 12 Mar 2000 15:20:49 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id RAA13639; Sun, 12 Mar 2000 17:24:06 -0600 (CST) (envelope-from jlemon) Date: Sun, 12 Mar 2000 17:24:06 -0600 (CST) From: Jonathan Lemon Message-Id: <200003122324.RAA13639@prism.flugsvamp.com> To: bugs@freebsd.netcom.com, hackers@freebsd.org Subject: Re: 5.0 features? X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: Organization: Cc: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: > >Something that the old DEC took a few stabs at was the idea of a >"checkpoint" feature where a process or a series of processes could be >put in a quiesced state. This would page out the process or processes >into the swap space, allow a hardware shutdown, and after a reboot allow >the restart of the checkpointed process(es). You might want to look at Condor , which does something similar; processes are allowed to be checkpointed and "migrated" to another machine. Sounds similar to what you describe above. It's fairly useful for high-throughput computing (making use of all/any idle CPU cycles). -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message