Re: bits/libc-lock.h and _LIBC

[Roland McGrath <roland@redhat.com>]

I don't think that bits/libc-lock.h should be useful outside of libc.
In fact, I think we should stop installing it.

The original intent of bits/libc-lock.h was to be used in user-visible
headers such as using __libc_lock_{lock,unlock} in the getc macro in
stdio.h.  (This was before the pthreads spec, and its interfaces for
locked/unlocked stdio streams, existed.)  For that use, the opaque types
are necessary to respect the ANSI C name space.  The other types and macros
for things that are not locks, and the unconditional inclusion of
pthread.h, were added to libc-lock.h when I was not involved and people
were not as anal about permitting this potential kind of use while meeting
the name space requirements.  It's now the case that we're sure no
user-visible header needs to use these macros.  Now we would probably avoid
introducing any such thing, and if such a need came up we would just use
the pthreads interfaces directly.

libio's data structure already has an indirection precisely to avoid the
user-visible header needing to know the lock type's layout.  libio-using
code can already just use the flockfile or _IO_flockfile interfaces.

The only installed header that in any way involves bits/libc-lock.h now is
libio.h.  So my plan is to stop installing it, and address libio.h and
bits/stdio-lock.h as follows.

Aside from compiling libc itself, there are two cases that matter.

1. code written for libio on a native glibc system, i.e. your own stream
   flavors with your own jump table, that would like to interact nicely
   with pthreads-enabled uses of stdio, so user defines _IO_MTSAFE_IO.

   For this, a bits/stdio-lock.h written in terms of pthreads interfaces
   directly would be fine.  pthread_cleanup_push/pop can't be referenced
   weakly (there're macros); but if you define _IO_MTSAFE_IO, you probably
   are linking with libpthread anyway.  (In the medium-term future, those
   will be done by try/finally and not have any link-time dependency, so
   using those and _IO_flockfile will make _IO_MTSAFE_IO users
   pthreads-aware but not pthreads-requiring.)

2. What you are talking about is sharing this libio source code for
   unrelated private uses in other packages.  (That is fine, but do
   remember that the primary role of the glibc sources is to build the
   whole libc as the system library for free operating systems.  The
   maintenance burden for supporting other uses of the sources needs to be
   kept minimal on us and the future us, unless it's required for other
   official GNU packages, as is the case with getopt and the various other
   shared sources.)  For that, you can supply whatever bits/stdio-lock.h
   header you want, it doesn't have to be the one in the libc sources.
   The pthreads-using version I am considering making glibc install now
   might well be just what you want, but it doesn't matter that glibc
   change for you to use a header that works for the way you are using the
   libio sources.

For compiling libc, things are already as they should be.  The current
sysdeps/generic/bits/stdio-lock.h can become include/bits/stdio-lock.h and
a pthreads-using version in sysdeps/pthread/bits/stdio-lock.h will be the
one installed.

I'm not sure what problem you might have that isn't solved by just using
your own bits/stdio-lock.h in the package where you've copied the libio
sources from glibc.  But is there any problem you have that isn't solved by
the header changes I described above?

Does anyone else see a problem with those changes?  I think case #1 is
reasonable enough to support, and I guess it's actually broken now.  But
more importantly I want to stop installing bits/libc-lock.h since it really
is an internal-only header, and having it there clearly confuses people.


Thanks,
Roland