From: Sebastian Huber <sebastian.huber@embedded-brains.de>
To: Alexandre Oliva <oliva@adacore.com>,
Jonathan Wakely <jwakely@redhat.com>
Cc: libstdc++ <libstdc++@gcc.gnu.org>,
gcc Patches <gcc-patches@gcc.gnu.org>, RTEMS <devel@rtems.org>
Subject: Re: [PATCH] libstdc++: retry removal of dir entries if dir removal fails
Date: Thu, 30 Jun 2022 10:19:09 +0200 [thread overview]
Message-ID: <8f26a8cf-fd6b-3f74-c3be-14cc29905814@embedded-brains.de> (raw)
In-Reply-To: <or7d4yvb9f.fsf@lxoliva.fsfla.org>
On 30/06/2022 09:52, Alexandre Oliva via Gcc-patches wrote:
> On Jun 27, 2022, Alexandre Oliva<oliva@adacore.com> wrote:
>
>> I see two potential ways to avoid this:
> Another possibility occurred to me: seeking back to the entry we're
> about to remove, before removing it. Then, POSIX-compliant
> implementations will just skip the removed entry and find the next one,
> while RTEMS will find the next entry at the spot where the removed entry
> used to be.
>
> It is syscall-heavier, and it may invoke O(n^2) behavior for each
> directory in remove_all, since prev_pos is quite likely to always hold
> the initial offset, requiring scanning past more and more removed
> entries after each removal, so I don't submit this formally for
> inclusion, but post it FTR. I've only confirmed that it solves the
> problem on RTEMS, passing libstdc++ filesystem test, but I haven't
> tested it further.
From my point of view this is behaviour is an RTEMS bug. Instead of
adding tweaks for RTEMS, it would be better to report the issues and fix
them in RTEMS. It could be also a Newlib issue.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
next prev parent reply other threads:[~2022-06-30 8:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-22 6:19 Alexandre Oliva
2022-06-22 9:45 ` Jonathan Wakely
2022-06-23 1:02 ` Alexandre Oliva
2022-06-27 13:27 ` Alexandre Oliva
2022-06-29 5:16 ` Alexandre Oliva
2022-06-30 7:52 ` Alexandre Oliva
2022-06-30 8:19 ` Sebastian Huber [this message]
2022-07-05 17:39 ` Alexandre Oliva
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8f26a8cf-fd6b-3f74-c3be-14cc29905814@embedded-brains.de \
--to=sebastian.huber@embedded-brains.de \
--cc=devel@rtems.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jwakely@redhat.com \
--cc=libstdc++@gcc.gnu.org \
--cc=oliva@adacore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).