Date: Tue, 24 Sep 1996 05:06:03 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Julian Elischer <julian@whistle.com> Cc: Jeffrey Hsu <hsu@freefall.freebsd.org>, jb@cimlogic.com.au, hackers@FreeBSD.org Subject: Re: libc_r bug Message-ID: <Pine.SV4.3.93.960924045857.16671A-100000@parkplace.cet.co.jp> In-Reply-To: <3245E79E.6EEA4806@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960924045857.16671A-100000>