Re: [RFC PATCH] fchdir: move fd shadowing into fd-hook

[Bruno Haible]

Hi Eric,

> In order to eventually add socket nonblocking status into
> fd shadowing, it is useful to move the existing fchdir name
> shadowing into a common file.

No, that's definitely not useful. On the contrary, it would make it
harder to write and maintain the code that stores the socket non-blocking
status in an array.

Gnulib is very modular, and therefore requires techniques to keep
independent code pieces in independent files, more than average programs.

We currently have two "hooks" for file descriptor operations:
  - fchdir.c, that stores the name of directories.
  - fd-hook.c and sockets.c, for close() and ioctl() on sockets.
We want to add a third one:
  - that stores the non-blocking status of file descriptors.

You're saying: let's merge the first two, so that adding the third one will
be easier. But this kills the modularity: separate things get mixed.
Instead, we need abstract infrastructure so that the third one can be added
_without_ affecting the first two ones.

It's really different things: In fchdir.c we deal only with file descriptors
that are directories, and store a string per fd. For the non-blocking status
we will deal only with sockets, and store a boolean per fd. The only common
thing is that both will need to hook into the 'dup', 'dup2', 'dup3', 'fcntl',
'close' functions.

You know what a CLOS :AROUND method and :AFTER method is? In CLOS [1][2][3],
you can hook in additional code to every function. This extra code is called
a "method". There are :AFTER methods, which are run after the function's
original code. In Java this concept is known as "listeners"; in Emacs Lisp it's
called a "hook". There are also :AROUND methods, which shadow that function's
original code but have the option to invoke that code.

We are doing this kind of things constantly in gnulib, but have it hardwired
in most places (for example lib/lstat.c is a typical code for an :AROUND method
added to lstat()). In the second case, however, we need the abstract
infrastructure, because we would get link dependencies otherwise.

So, in the CLOS speak,
  - fchdir.c are :AROUND methods for 'dup', 'dup2', 'dup3', 'fcntl', 'close',
    open(), fdopendir().
  - fd-hook.c and sockets.c are :AROUND methods for 'ioctl', 'close'.
  - for the non-blocking status we need :AROUND methods for 'dup', 'dup2',
    'dup3', 'fcntl', 'close'.

Now there are two ways to proceed:

  a) Formalize the notion of a set of :AROUND methods for 'dup', 'dup2',
     'dup3', 'fcntl', 'close', in such a way that the first and third code
     can share the same infrastructure. That would mean a file fd-hook2.c,
     similar to fd-hook.c but just with other functions to hook in.

  b) Search for all uses of "#if REPLACE_FCHDIR" and add a
     "#if WINDOWS_NONBLOCKING" section next to it (before or after, does not
     matter, since they operate independently).

Approach a) is IMO overkill, because we don't have to deal with link
dependencies for the third case, like we didn't need for fchdir.

So I think approach b) is the way to go.

Bruno

[1] 
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_7-6-6-2.html
[2] http://www.aiai.ed.ac.uk/~jeff/clos-guide.html#generic
[3] http://www.apl.jhu.edu/~hall/AI-Programming/CLOS.html#HEADING1-89
-- 
In memoriam Heinz Droßel <http://en.wikipedia.org/wiki/Heinz_Drossel>