Date: Tue, 18 Mar 1997 23:36:12 -0800 (PST) From: Mike Pritchard <mpp> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: hackers@freebsd.org Subject: Re: dup3() - I've thought it over and decided... Message-ID: <199703190736.XAA09452@freefall.freebsd.org> In-Reply-To: <20163.858754119@time.cdrom.com> from "Jordan K. Hubbard" at Mar 18, 97 10:48:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703190736.XAA09452>