From owner-freebsd-hackers  Tue Mar 18 22:48:42 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id WAA15965
          for hackers-outgoing; Tue, 18 Mar 1997 22:48:42 -0800 (PST)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA15881
          for <hackers@freebsd.org>; Tue, 18 Mar 1997 22:48:40 -0800 (PST)
Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id WAA20167 for <hackers@freebsd.org>; Tue, 18 Mar 1997 22:48:40 -0800 (PST)
To: hackers@freebsd.org
Subject: dup3() - I've thought it over and decided...
Date: Tue, 18 Mar 1997 22:48:39 -0800
Message-ID: <20163.858754119@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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.. :)

					Jordan