Message-Id: <3.0.1.32.19971202130439.007ae100@yacker.xiotech.com>
Date: Tue, 02 Dec 1997 13:04:39 -0600
To: DJ Delorie <dj AT delorie DOT com>
From: Randy Maas <randym AT acm DOT org>
Subject: Re: patch for fsext.h
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <199712020039.TAA26761@delorie.com>
References: <3 DOT 0 DOT 1 DOT 32 DOT 19971201075639 DOT 007f8270 AT yacker DOT xiotech DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

At 07:39 PM 12/1/97 -0500, you wrote:
>Would it make more sense to have a separate pair of calls:
>	void *_fsext_get_data(int fd);
>	void *_fsext_set_data(int fd, void *);
>
>Since "fd" is usually a small int (0..255) we can easily make an array
>of these pointers, and the extensions that don't use extra data won't
>have to change at all, nor will the clients (libc functions).


Good points.  There is probably something wrong if more than 255 fsext
"files" are open anyway.

I can't speak for anyone else, but I've been experimenting with making some
fsexts loadable (as a dxe).  I have a style preference for the data being
passed as a parameter -- the smaller the set of fsext support functions to
export the better 8)   Its not difficult to work around tho'.

It sounds like you are suggesting implementing a second, but smaller, table
to map fd to data (or "state").  My guess (or hope?) is about 40% of the
open fsext files will want data associated with the fd.  Instead of one
potential page-in, this may cause two page-ins -- one for the fd to handler
mapping and one for the fd to data mapping...

Another implementation could be _fsext_XXX_data and _fsext_XXX_functions
sharing a hash table of:

struct {
   int fd;
  __FSEXT_function* func;
  void* data;
};

This should be able to fit 340 or so on a single page.  I'd say use fd as
the hash key.  The big drawback is the penalty for updating and searching
the list, possibly twice.  Any idea if the average case under two tables is
worse or better than the average case under searching one hash table?

> We need to ensure that the fsext always has an opportunity
>to clean up, and that it takes advantage of that opportunity.

I think you are saying that the fsext will still have data hanging around
even after close()'ing all its open files.  If thats the case: should we
have a convention that a fsext not have any allocated resources while it
has no open files?  This may cause a open' penalty for the fsext's that use
such resources to speed up open, but  not too many opens are really gonna
happen... atleast outside of emacs and a web server/client.

Randy