Re: Unlink failure on abort

[David Boyce]

In the event this patch is used: I think the interleaved-ifdef style is hard to read and best avoided. How about either separating the Windows and "other" clauses at the top level or something like this (with suitable comment):

+      for (e = 0; e < 10; ++e)

+        {

+          status = unlink (file->name);

+#ifdef WINDOWS32

+          if (status == 0 || errno == ENOENT)

+            break;

+          Sleep(5);

+#else

+          break;

+        }

+#endif

On Sat, Jun 17, 2017 at 10:02 PM, Orgad Shaneh <address@hidden> wrote:

On Sun, Jun 18, 2017 at 5:31 AM, Eli Zaretskii <address@hidden> wrote:

> From: Orgad Shaneh <address@hidden>
> Date: Sat, 17 Jun 2017 23:04:11 +0300
> Cc: address@hidden, Alexey Pavlov <address@hidden>
>
> +#ifdef WINDOWS32
> +      for (e = 0; e < 10; ++e)
> +        {
> +#endif
> +          status = unlink (file->name);
> +#ifdef WINDOWS32
> +          if (status == 0 || errno == ENOENT)
> +            break;
> +          Sleep(50);
> +        }
> +#endif

Please try the same, but with Sleep calls using 10 or even 5 msec (and
enlarging the loop count if necessary).  I'd be interested to see the
statistics of the count after which the unlink call succeeds in your
cases.

Thanks.

On my machine it also doesn't reproduce every time, but I can reproduce it.

I used Sleep(5), and had count of 2 (I had the same with Sleep(50)).

I think the problem is that reap_children() is called after delete_child_targets, so the child jobs can still run while make is trying to delete.

Maybe delete_targets should become part of reap_children (it cannot be called after reap, because at this point you don't have the target info anymore).

What do you say?

- Orgad

_______________________________________________
Bug-make mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-make