From owner-freebsd-hackers Wed Mar 19 13:35:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA04549 for hackers-outgoing; Wed, 19 Mar 1997 13:35:57 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA04447 for ; Wed, 19 Mar 1997 13:35:54 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA12436; Wed, 19 Mar 1997 14:21:58 -0700 From: Terry Lambert Message-Id: <199703192121.OAA12436@phaeton.artisoft.com> Subject: Re: dup3() - I've thought it over and decided... To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 19 Mar 1997 14:21:58 -0700 (MST) 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] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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.. :) Gee, too bad descriptors aren't implemented using process logical names that you can modify from other processes... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.