Date: Wed, 19 Mar 1997 03:35:39 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Stephen McKay <syssgm@dtir.qld.gov.au> Cc: freebsd-hackers@freebsd.org Subject: Re: dup3() - I've thought it over and decided... Message-ID: <5569.858771339@time.cdrom.com> In-Reply-To: Your message of "Wed, 19 Mar 1997 20:04:41 %2B1000." <199703191004.UAA22114@ogre.dtir.qld.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Look at the "screen" port. It can do this detach/reattach stuff even if > you only use one screen. It uses pseudo terminals, of course. Wonderful > stuff. No need for checkpointing processes. Erm. I do beg to differ. Several people have pointed out various PTY-using schemes as The Answer when it's painfully clear that PTYs are a scarce and inefficient resource that don't stand a chance of scaling to the task at hand - more generalized process management. Perhaps if we had a light-weight, cloning PTY driver and the business of acquiring a new one was very fast then that would be a very different thing, but for now we have a lot of gross code in libutil which runs around trying to open everything in sight until it succeeds. :-) 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. 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?5569.858771339>