* bits/libc-lock.h and _LIBC @ 2002-10-22 6:51 Thorsten Kukuk 2002-11-04 1:29 ` Ulrich Drepper 2002-11-08 9:57 ` Roland McGrath 0 siblings, 2 replies; 5+ messages in thread From: Thorsten Kukuk @ 2002-10-22 6:51 UTC (permalink / raw) To: libc-hacker; +Cc: drepper 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bits/libc-lock.h and _LIBC 2002-10-22 6:51 bits/libc-lock.h and _LIBC Thorsten Kukuk @ 2002-11-04 1:29 ` Ulrich Drepper 2002-11-04 1:32 ` Thorsten Kukuk 2002-11-08 9:57 ` Roland McGrath 1 sibling, 1 reply; 5+ messages in thread From: Ulrich Drepper @ 2002-11-04 1:29 UTC (permalink / raw) To: Thorsten Kukuk; +Cc: libc-hacker -----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----- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bits/libc-lock.h and _LIBC 2002-11-04 1:29 ` Ulrich Drepper @ 2002-11-04 1:32 ` Thorsten Kukuk 2002-11-04 1:46 ` Ulrich Drepper 0 siblings, 1 reply; 5+ messages in thread From: Thorsten Kukuk @ 2002-11-04 1:32 UTC (permalink / raw) To: Ulrich Drepper; +Cc: libc-hacker 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bits/libc-lock.h and _LIBC 2002-11-04 1:32 ` Thorsten Kukuk @ 2002-11-04 1:46 ` Ulrich Drepper 0 siblings, 0 replies; 5+ messages in thread From: Ulrich Drepper @ 2002-11-04 1:46 UTC (permalink / raw) To: Thorsten Kukuk; +Cc: libc-hacker -----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----- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bits/libc-lock.h and _LIBC 2002-10-22 6:51 bits/libc-lock.h and _LIBC Thorsten Kukuk 2002-11-04 1:29 ` Ulrich Drepper @ 2002-11-08 9:57 ` Roland McGrath 1 sibling, 0 replies; 5+ messages in thread From: Roland McGrath @ 2002-11-08 9:57 UTC (permalink / raw) To: Thorsten Kukuk; +Cc: libc-hacker 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-11-08 17:57 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-10-22 6:51 bits/libc-lock.h and _LIBC Thorsten Kukuk 2002-11-04 1:29 ` Ulrich Drepper 2002-11-04 1:32 ` Thorsten Kukuk 2002-11-04 1:46 ` Ulrich Drepper 2002-11-08 9:57 ` Roland McGrath
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).