glibc/libio/bits
Alexandre Ferrieux 2a99e2398d 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>
2024-05-17 14:13:25 -07:00
..
types Use a doubly-linked list for _IO_list_all (bug 27777) 2024-05-17 14:13:25 -07:00
stdio2-decl.h Update copyright dates with scripts/update-copyrights 2024-01-01 10:53:40 -08:00
stdio2.h libio: Improve fortify with clang 2024-02-27 10:52:58 -03:00
stdio-ldbl.h Refer to C23 in place of C2X in glibc 2024-02-01 11:02:01 +00:00
stdio.h Update copyright dates with scripts/update-copyrights 2024-01-01 10:53:40 -08:00