bits/libc-lock.h and _LIBC

bits/libc-lock.h and _LIBC

[Thorsten Kukuk]

Hi,

We install libc-lock.h into /usr/include/bits. But libc-lock.h is
only useable, if it is compiled with -D_LIBC, which breaks now with
libio.h.

I suggest the following patch, or is there any reason for the
ifdef _LIBC around __libc_lock_t ? We don't do this for __libc_key_t
and all the other definitions.

2002-10-17  Thorsten Kukuk  <kukuk@suse.de>

	* sysdeps/pthread/bits/libc-lock.h: Don't protect __libc_lock_t
	with _LIBC.

diff -u -r1.23 libc-lock.h
--- ./linuxthreads/sysdeps/pthread/bits/libc-lock.h
+++ ./linuxthreads/sysdeps/pthread/bits/libc-lock.h
@@ -24,19 +24,9 @@
 #include <pthread.h>
 
 /* Mutex type.  */
-#if defined(_LIBC) || defined(_IO_MTSAFE_IO)
 typedef pthread_mutex_t __libc_lock_t;
 typedef struct { pthread_mutex_t mutex; } __libc_lock_recursive_t;
-# ifdef __USE_UNIX98
 typedef pthread_rwlock_t __libc_rwlock_t;
-# else
-typedef struct __libc_rwlock_opaque__ __libc_rwlock_t;
-# endif
-#else
-typedef struct __libc_lock_opaque__ __libc_lock_t;
-typedef struct __libc_lock_recursive_opaque__ __libc_lock_recursive_t;
-typedef struct __libc_rwlock_opaque__ __libc_rwlock_t;
-#endif
 
 /* Type for key to thread-specific data.  */
 typedef pthread_key_t __libc_key_t;


-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Deutschherrnstr. 15-19        D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

Re: bits/libc-lock.h and _LIBC

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thorsten Kukuk wrote:

> We install libc-lock.h into /usr/include/bits. But libc-lock.h is
> only useable, if it is compiled with -D_LIBC, which breaks now with
> libio.h.

What exactly fails?  And when did it change?  The header is in this form
installed on my systems and I have no problems using <libio.h>.


> I suggest the following patch, or is there any reason for the
> ifdef _LIBC around __libc_lock_t ? We don't do this for __libc_key_t
> and all the other definitions.

I've made the types opaque back when for a good reason.  I think it was
mainly the use in libstdc++ but also to prevent any kind of initializers.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9xj3q2ijCOnn/RHQRAnX8AJ9wl29zf64OnXqvkXZWqneItRCaFQCghBRG
Ix7S2+hU1/KMnaW6RCdczBM=
=K3X3
-----END PGP SIGNATURE-----

Re: bits/libc-lock.h and _LIBC

[Thorsten Kukuk]

On Mon, Nov 04, Ulrich Drepper wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thorsten Kukuk wrote:
> 
> > We install libc-lock.h into /usr/include/bits. But libc-lock.h is
> > only useable, if it is compiled with -D_LIBC, which breaks now with
> > libio.h.
> 
> What exactly fails?  And when did it change?  The header is in this form
> installed on my systems and I have no problems using <libio.h>.

The nss_db package, for example.
libio.h uses some glibc internal things like attribute hidden, if
_LIBC is defined, but without _LIBC defined, bits/libc-lock.h use
useless.

 
> > I suggest the following patch, or is there any reason for the
> > ifdef _LIBC around __libc_lock_t ? We don't do this for __libc_key_t
> > and all the other definitions.
> 
> I've made the types opaque back when for a good reason.  I think it was
> mainly the use in libstdc++ but also to prevent any kind of initializers.

Than do it for all or for nothing. If you currently wish to use
libc-lock.h, you need to define _LIBC, but if you do this, you
cannot include something, which includes libio.h, afterwards.

The current bits/libc-lock.h behavior is inconsistent.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Deutschherrnstr. 15-19        D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

Re: bits/libc-lock.h and _LIBC

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thorsten Kukuk wrote:

> The nss_db package, for example.
> libio.h uses some glibc internal things like attribute hidden, if
> _LIBC is defined, but without _LIBC defined, bits/libc-lock.h use
> useless.

It's not useless.  It's included in <stdio.h> and obviously works well.

If nss_db has problems this might just mean it has to be changed.


> The current bits/libc-lock.h behavior is inconsistent.

That's completely irrelevant.  The existing definitions are in their
current form because there have been problems.  The rest works just
fine.  No reason whatsoever to change anything.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9xkIe2ijCOnn/RHQRAjbrAJ4m/3pLgIM4nhYMT8lQnKOgNDCLhwCgwlLo
jkkTkBQPVHaEgo4vjeww7J0=
=jNO4
-----END PGP SIGNATURE-----

Re: bits/libc-lock.h and _LIBC

[Roland McGrath]

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