Eric Blake wrote: > > What about the FD table; should it be a hash table, a binary tree, an > > ordered linked list, or something else entirely? > > Gnulib already provides the gl_list module. The idea there is that you start > by coding with an array list (probably a good choice anyways, since the > underlying kernel also maintains an array of open fds, and since it seems to > me > that you are always going from fd to name, never a reverse lookup), work out > the bugs, then decide if some other representation, such as an AVL tree list, > would be more efficient for the typical usage pattern of the list. Once you > use the gl_list API, it is only a one-line code change and reinvocation of > gnulib-tool to pick up the new underlying list implementation.
This is all true, but I think using gl_list is an overkill here: All known libc or kernel implementations have a per-process array of file descriptors, where the information of each file descriptor (the file it refers to, whether it's inheritable or not, etc.) is stored. So, you can assume that an fd is a _small_ integer >= 0. Some systems make this assumption even more explicit by providing a getdtablesize() function. So, the representation I would prefer would be a resizable, malloc()ed array. No need to bother calling getdtablesize(). Bruno
