From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31291 invoked by alias); 8 Nov 2002 17:57:54 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 31269 invoked from network); 8 Nov 2002 17:57:52 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.212.31) by sources.redhat.com with SMTP; 8 Nov 2002 17:57:52 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 53E41357E; Fri, 8 Nov 2002 09:57:51 -0800 (PST) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id gA8HvoJ05389; Fri, 8 Nov 2002 09:57:50 -0800 Date: Fri, 08 Nov 2002 09:57:00 -0000 Message-Id: <200211081757.gA8HvoJ05389@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Thorsten Kukuk Cc: libc-hacker@sources.redhat.com Subject: Re: bits/libc-lock.h and _LIBC In-Reply-To: Thorsten Kukuk's message of Monday, 21 October 2002 11:27:36 +0200 <20021021112734.A25309@suse.de> X-Shopping-List: (1) Prodigious potion docks (2) Parsimonious trout (3) Conscious tabular mouse pigs (4) Burnt trout X-SW-Source: 2002-11/txt/msg00039.txt.bz2 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