MAX_OPEN_FILES etc ...

[Andrew Tridgell]

> I disagree.
> 
> The performace hit will be *very* large (cumulatively)
> by changing these macros to functions.
> 
> The Files structure is accessed *everwhere*. IMHO It is not
> practical in terms of performace to move access macros 
> out into a separate file accessed only by functions.
> The Files[] macros are probably used more than the
> DEBUG macro over all the code.

Jeremy and I discussed this and decided that instead something like
this would be good:

1) hide all the data structures holding lists of open files files.c
2) leave the main structure definition available to all modules, so if
   a module has a pointer to a file structure it can access elements
   directly. 
3) provide access functions that return pointers to a file structure.

so all the inter-structure accesses (ie. looping) have to be done by
code in files.c, but within structure accesses can be done by anyone. 

Perhaps I should explain my motivations behind changing from a Files[]
array.

There are places in Samba when we are given a key and we have to find
a matching file structure in the Files[] array. The main place I am
thinking of is in the oplock code, where we are given a device/inode
from another smbd and need to find our Files[] element which
matches. Currently we do that via a loop over the whole Files[]
array. As we expand the Files[] array to many thousands of elements
that loop will get very slow! It is crying out for a hash table with
maybe 100 hash keys and hash chains coming off the hash table
entries. This is easy to implement but doing it as things stand
would mean putting hash table code everywhere. By moving Files[] into
files.c we can add a hash table in one place.

So as long as the structures which tell Samba how to loop through
Files[] to find particular elements are hidden in files.c I will be
happy :)

      Cheers, Tridge