From owner-freebsd-hackers Mon Sep 23 13:06:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA24199 for hackers-outgoing; Mon, 23 Sep 1996 13:06:22 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA24174 for ; Mon, 23 Sep 1996 13:06:16 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.6/CET-v2.1) with SMTP id UAA16729; Mon, 23 Sep 1996 20:06:03 GMT Date: Tue, 24 Sep 1996 05:06:03 +0900 (JST) From: Michael Hancock To: Julian Elischer cc: Jeffrey Hsu , jb@cimlogic.com.au, hackers@FreeBSD.org Subject: Re: libc_r bug In-Reply-To: <3245E79E.6EEA4806@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 22 Sep 1996, Julian Elischer wrote: > Michael Hancock wrote: > > > > On Sat, 21 Sep 1996, Jeffrey Hsu wrote: > > > > > > _thread_fd_table_init() just sets up > > > > the table for a fd. fds 0, 1 and 2 don't have to be valid. > > > > > > Since we can't tell whether a given fd might need a call to > > > _thread_fd_table_init() or not, the correctness before all else > > > principle would argue for either pre-allocating all the fd entries > > > or doing it on demand by placing a call to _thread_fd_table_init() > > > in write() and all the other places where it might be needed. Of > > > these two, I prefer the second. What about you? > > > > > > > I prefer on demand too. > but what's the overhead on every file operation? Pre-allocating kind of implies fixed, but I guess it doesn't have to. For performance it would be better to pre-allocate at the expense of space. Maybe you can pre-allocate a chunk and dynamically allocate more chunks based on high water marks. Or maybe just implement a simple algorithm first that works correctly and optimize later when you understand more aspects of the problem. Regards, Mike Hancock