This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |