From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89015 invoked by alias); 6 Apr 2017 22:06:24 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 88972 invoked by uid 89); 6 Apr 2017 22:06:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=month X-HELO: mx1.redhat.com DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2F78D2DC34C Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2F78D2DC34C Subject: Re: [PATCH 1/2] Remove _IO_MTSAFE_IO from public headers. To: Adhemerval Zanella , Zack Weinberg References: <20170322125504.4863-1-zackw@panix.com> <20170322125504.4863-2-zackw@panix.com> <87a4474b-e4c8-fda7-1d8e-888e0446a984@linaro.org> Cc: GNU C Library From: Florian Weimer Message-ID: Date: Thu, 06 Apr 2017 22:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87a4474b-e4c8-fda7-1d8e-888e0446a984@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-04/txt/msg00124.txt.bz2 On 04/06/2017 11:29 PM, Adhemerval Zanella wrote: > > > On 06/04/2017 17:41, Zack Weinberg wrote: >> On Thu, Apr 6, 2017 at 4:29 PM, Adhemerval Zanella >> wrote: >>> On 22/03/2017 09:55, Zack Weinberg wrote: >>>> _IO_MTSAFE_IO controls whether stdio is *built* with support for >>>> multithreading. In the distant past it might also have worked as a >>>> feature selection macro, allowing library *users* to select >>>> thread-safe or lock-free stdio at application build time, I haven't >>>> done the archaeology. Nowadays, defining _IO_MTSAFE_IO while using >>>> the installed headers, or in _ISOMAC mode, will cause libio.h to throw >>>> syntax errors. >>> >>> What prevent us to just get rid of _IO_MTSAFE_IO and just build/assume >>> stdio with multithread support? >> >> I think that's a desirable goal, but I don't want to do that in this >> patchset because I suspect it will be messy *inside* libc. And I'd >> start by getting it out of the public headers, anyway. > > Why do you think so? The make fragment sysdeps/pthread/Makeconfig already > sets libc-reentrant regardless, so _IO_MTSAFE_IO is already being defined > in all objects that might use it (and I suspect it has been this way for > some time already). There is some oddity going on with regards to the libio locking macros. A previous discussion: (spans into next month) Obviously, we need to clean this up, but we need to be careful to preserve the locking behavior expected by applications. Thanks, Florian