From owner-freebsd-hackers Tue Mar 18 23:36:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA09469 for hackers-outgoing; Tue, 18 Mar 1997 23:36:17 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA09452; Tue, 18 Mar 1997 23:36:13 -0800 (PST) From: Mike Pritchard Message-Id: <199703190736.XAA09452@freefall.freebsd.org> Subject: Re: dup3() - I've thought it over and decided... To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 18 Mar 1997 23:36:12 -0800 (PST) Cc: hackers@freebsd.org In-Reply-To: <20163.858754119@time.cdrom.com> from "Jordan K. Hubbard" at Mar 18, 97 10:48:39 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > > It's a hack. Forget about it. :-) > > That said, I think that there's a need for a more generalized I/O > model which allows this kind of in-flight disconnection and > reconnection of I/O handles a process might have open, but it needs to > be a lot more involved than just thwapping over somebody's file > handles. :-) There needs to be some mechanism for flushing or > discarding pending I/O on reconnect, for one thing, and it needs to > play friendly with stdio. > > I'll think about the problem some more.. :) How about going more along the checkpoint/restart route? Suspend the process, checkpoint it, and on restart you can reconnect stdin/out/err to either the current tty, or to another file. Reconnecting to a pipeline should also be possible. I can dig up the USENIX paper the Cray guys wrote on this if you like :-). Like you, I often do something like: % some long running command that generates output [oh, I have to go, geez, I wish I had redirected the output, darn...] ^C % nohup same_command >& out -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn"