This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Single threaded stdio optimization
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: nd at arm dot com, "triegel at redhat dot com" <triegel at redhat dot com>
- Date: Fri, 07 Jul 2017 16:02:16 +0100
- Subject: Re: [PATCH v2] Single threaded stdio optimization
- Authentication-results: sourceware.org; auth=none
- Authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <594AA0A4.7010600@arm.com> <a48172d4-1d98-43e2-31c5-05042e12a082@redhat.com> <595F8EBA.1030305@arm.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 07/07/17 14:38, Szabolcs Nagy wrote:
> On 07/07/17 13:38, Florian Weimer wrote:
>> This patch breaks the attached test case. Not all stream objects are
>> linked into the global list, so the locking upgrade doesn't happen for
>> some of them.
>>
>
> i thought all files need to be flushed on exit
> or on fflush(0), if glibc does not do that that's
> observably non-conforming.
>
>> The global list management is quite expensive because the list is
>> single-linked, so we can't just add all stream objects when not yet
>> running multi-threaded.
>>
>> I fear that this patch may have to be backed out again, until we can
>> address these issues.
>>
>
> i can back it out, or try to create all the
> problematic files with the optimization-disabling
> flag set (in case that's simple.. will look into
> it in a minute).
>
it seems both changing the optimization flag or adding
these streams to the list are easy.
i think glibc should just fix the open_memstream bug,
https://sourceware.org/bugzilla/show_bug.cgi?id=21735
i'll work on a patch.
(i don't expect a large number of open/close memstream
operations, so it should not have a huge impact)