[Bug stdio/27777] fclose does a linear search, takes ages when many FILE* are opened

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27777

--- Comment #6 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=2a99e2398d9d717c034e915f7846a49e623f5450

commit 2a99e2398d9d717c034e915f7846a49e623f5450
Author: Alexandre Ferrieux <alexandre.ferrieux@orange.com>
Date:   Thu May 16 05:54:30 2024 -0700

    Use a doubly-linked list for _IO_list_all (bug 27777)

    This patch fixes BZ #27777 "fclose does a linear search, takes ages when
    many FILE* are opened".  Simply put, the master list of opened (FILE*),
    namely _IO_list_all, is a singly-linked list.  As a consequence, the
    removal of a single element is in O(N), which cripples the performance
    of fclose().  The patch switches to a doubly-linked list, yielding O(1)
    removal.  The one padding field in struct _IO_FILE, __pad5, is renamed
    to _prevchain for a doubly-linked list.  Since fields in struct _IO_FILE
    after the _lock field are internal to glibc and opaque to applications.
    We can change them as long as the size of struct _IO_FILE is unchanged,
    which is checked as the part of glibc ABI with sizes of _IO_2_1_stdin_,
    _IO_2_1_stdout_ and _IO_2_1_stderr_.

    NB: When _IO_vtable_offset (fp) == 0, copy relocation will cover the
    whole struct _IO_FILE.  Otherwise, only fields up to the _lock field
    will be copied to applications at run-time.  It is used to check if
    the _prevchain field can be safely accessed.

    After opening 2 million (FILE*), the fclose() of 100 of them takes quite
    a few seconds without the patch, and under 2 seconds with it on a loaded
    machine.

    No test is added since there are no functional changes.

    Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>
    Signed-off-by: Alexandre Ferrieux <alexandre.ferrieux@orange.com>
    Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
    Reviewed-by: Carlos O'Donell <carlos@redhat.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.