This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: _IO_MTSAFE_IO
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: <nd at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 8 May 2017 18:48:17 +0100
- Subject: Re: _IO_MTSAFE_IO
- Authentication-results: sourceware.org; auth=none
- Authentication-results: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <572316A7.2060209@redhat.com> <alpine.DEB.2.20.1604291430410.10400@digraph.polyomino.org.uk> <572710AC.6030603@redhat.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 02/05/16 09:32, Florian Weimer wrote:
> On 04/29/2016 04:36 PM, Joseph Myers wrote:
>> On Fri, 29 Apr 2016, Florian Weimer wrote:
>>
>>> Whether applications can use these macros is somewhat debatable, but as I
>>> said, it happens within glibc as well. There are repeated occurrences of this
>>
>> My view would be:
>>
>> * libio is not a public API for applications; only stdio is (and internals
>> should be avoided in public headers where possible). But ABI
>> compatibility with old applications using libio may still be needed.
>
> Yes, we need the ABI compatibility. I believe some of the stdio macros need <libio.h> or something like it, too.
>
>> * _IO_* symbols may be used internally in glibc for namespace reasons
>> (where they are function aliases), or if there is another reason for using
>> internals of another part of glibc.
>
> Makes sense.
>
>>> Curiously, _IO_flockfile and _IO_funlockfile are only defined in
>>> libpthread.so, not in libc.so. But these implementations are slightly
>>
>> They seem to be in the libc.abilist files to me....
>
> Yes, I remembered incorrectly, I got a localplt failure during building. So there currently aren't any
> _IO_flockfile references in libc.so, they are either expanded inline or they are elided.
>
> I thought about the _IO_flockfile discrepancy some more. I believe we should do the following:
>
> (1) Replace _IO_flockfile references with a new internal function (say __flockfile_nouser). This new function
> will perform the _IO_USER_LOCK check.
>
> (2) Remove the symbols currently controlled by _IO_MTSAFE_IO from the API (header file at first, almost of
> _IO_* needs to be made compat-only, as you pointed out, but this is a different issue).
>
this would be nice to sort out.
i'd propose a related single threaded optimization:
make all stdio apis with _unlocked variant do a check on
the FILE* that tells if the process is multithreaded or
the stream was ever locked, if not then just tailcall the
_unlocked code.
this approach would be more efficient for _IO_USER_LOCK
too which currently does redundant operations.
when the first thread is created, the FILE* with the
optimization have to be updated (and future FILE*
should be created with different initializer), but
this should be possible to do.
the current stdio locking code is slow for single thread
case which is a common usecase (i can measure >10x diff
between getc and getc_unlocked on a machine with admittedly
slow atomics), and i don't think the check would add too
much overhead for the threaded case (e.g. the lock owner
field may be used which is checked anyway).
(x86 seems to have a single thread optimization in libc.so
for lowlevelocks, that is suboptimal and seems to be broken
for pshared locks, it only works because there are no such
locks currently in libc.so, i think higher level target
independent optimization would be better for stdio. malloc
may be a different story, other apis using lll are probably
not performance critical in a single threaded context)