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 18:30:52 +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> <595FA278.3040708@arm.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 07/07/17 16:02, Szabolcs Nagy wrote:
> 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)
>
sorry, i cannot work on this until monday,
i hope it's ok to leave multithread open_memstream
broken for a few days.