Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!randvax!segue!jim
From: jim@segue.segue.com (Jim Balter)
Newsgroups: comp.unix.internals
Subject: Re: Shared Lib Question (ISC)
Message-ID: <7616@segue.segue.com>
Date: 20 May 91 09:50:45 GMT
References: <519a6ad6.20b6d@apollo.HP.COM>
Reply-To: jim@segue.segue.com (Jim Balter)
Organization: Segue Software, Inc. - Santa Monica, CA. +1-213-453-2161
Lines: 19

In article <519a6ad6.20b6d@apollo.HP.COM> goykhman_a@apollo.HP.COM (Alex Goykhman) writes:
>    Fclose(NULL) is only defined within the context of a single process, all it 
>    needs to do is to go through the per-process fd table and and close every fd that
>    remains open.  It should be easy to implement this call as a part of a shared
>    library, and I am not sure what kind of overhead you are referring to.

The subject at hand was global data, not ease of implementation.  In order to
implement fclose(NULL), there must be a global pointer to the head of a list of
FILE's, or a global table of FILE's.  Of course, given the global data, the
implementation is trivial.  The fd table is in the u-structure and isn't really
relevant to a discussion of stdio routines (unless you want to provide a system
call to allow a shared lirbary to access global data saved in the u-structure;
a conceptually intresting but non-pragmatic approach).  Note that I brought up
fclose(NULL) because it is contrary to jfh's point about pointers to state info
(FILE *) being explicitly passed to stdio routines.

The overhead referred to is the overhead of a wrapper routine to pass the
global data (maintained per-process) to the "real" routine in the shared
library.  This was all pretty evident from a careful reading of the thread.