Date: Wed, 19 Mar 1997 09:47:31 -0600 From: Chris Csanady <ccsanady@nyx.pr.mcs.net> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Stephen McKay <syssgm@dtir.qld.gov.au>, freebsd-hackers@freebsd.org Subject: Re: dup3() - I've thought it over and decided... Message-ID: <199703191547.JAA01236@nyx.pr.mcs.net> In-Reply-To: Your message of Wed, 19 Mar 1997 03:35:39 -0800. <5569.858771339@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[snip] > >Besides, there are other reasons for implementing checkpointing than >just this. Common scenario: You're 5 hours into a 7 hour build when >the printer device wedges hard and it become clear that only a reboot >will fix it. Your wife is clamoring for the printer. She needs it >now? What to do? Well, if this were a more elegant system, you'd >simply say "no problem, dear, let me just save my build." and you'd >suspend the make, checkpoint your login shell (taking your sleeping >make world with it as a child) and reboot the system. Checkpointing would be a real plus for FreeBSD imho. With respect to cost/performance, you cant really beat PPros now, and they seem to be showing up more in scientific computing uses. Last time I checked, we were going to buy Hibernator for our Onyx, (yes, just a 1 machine license..) and it was something like $10k. This is utterly rediculous. Anyways, I think if FreeBSD had something similar, it would give us a nice edge in this type of market. --Chris Csanady > >Once you're back, you invoke a new shell from the saved image and >forground your make, all as it was. > >Of course there are certainly problems with this rosy picture. "What >happens to all of the processes' external dependencies?" I hear you >ask. "All the sockets it may have had open, the files half-read, the >shared memory segments referenced..." > >Naturally, resurrection isn't going to be a pretty process. It'd be a >bit like resucitating a half-drowned corpse, really - you might get >the person back, but they'll never be entirely the same. If you can >get it to work well in 90% of the cases it's used, however, I think >it'll be useful nonetheless. This would, strangely enough, be another >area where a more flexible I/O connection model would really help. If >the reanimator function had a way of easily walking the list of open >I/O objects the process had and invalidating the ones which were no >longer viable (timed-out network objects, for example, or pointers to >inode objects which have been freed/reclaimed) by simply closing them >or substituting in a reference to /dev/null, that would greatly >simplify things. Because you'd already have provisions for a >process's I/O being abruptly redirected elsewhere (like the >bit-bucket), resurrection wouldn't be such a rude shock to the >process. > >> Then again, maybe we could get a good TOPS-10 emulation going. Had lots >> of fun in the Good Old Days(tm) of University detaching and reattaching > >Who needs TOPS-10 emulation? Just run the genuine OS under the PDP-10 >machine emulator. :-) The author was threatening to port it to >something non-sparc last time I talked to him. ;) > > Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703191547.JAA01236>