Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.unix.questions Subject: Re: File descriptors Message-ID: <5881@brl-smoke.ARPA> Date: Fri, 22-May-87 19:16:51 EDT Article-I.D.: brl-smok.5881 Posted: Fri May 22 19:16:51 1987 Date-Received: Tue, 26-May-87 02:21:25 EDT References: <2532@ncoast.UUCP> <5875@brl-smoke.ARPA> <1673@tekcrl.TEK.COM> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 20 In article <1673@tekcrl.TEK.COM> terryl@tekcrl.tek.com writes: >Doug, you really blew it on this one. Ahem, I certainly am aware that the file-descriptor is an index into a per-process data structure, which I chose to call an "open-file table" both for simplicity (after all, if the inquirer knew all this stuff he wouldn't be asking the question) and because that's what Ken Thompson called it in the cited article. Actually, he explained the distinction between the "per-user open file table", which is what I was describing, and the more global "open file table". The only reason there are two such tables rather than one is to permit the sharing of the file position pointer across a fork. I don't see the necessity for this particular characteristic (I can't recall ever having made use of it), so as far as I'm concerned there might as well be only one open-file table. File descriptors could then be unique indices into the system table. (The other use for per-process indices is that one can then guarantee the use of small values such as 0, 1, and 2.) I didn't feel it was worth trying to explain this two- level aspect of the open file tables when the inquirer would undoubtedly be happy to get any definite grasp of the concept.