This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] Remove _IO_MTSAFE_IO from public headers.
On 06/04/2017 19:06, Florian Weimer wrote:
> 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
>>> <adhemerval.zanella@linaro.org> 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:
>
> <https://sourceware.org/ml/libc-alpha/2016-04/msg00748.html>
> (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
Right, removing _IO_MTSAFE_IO seems no be not a trivial issue. I think
we can push it in the future then.