Re: [PATCH 1/2] Remove _IO_MTSAFE_IO from public headers.

[Florian Weimer <fweimer at redhat dot com>]

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