On Sun, Jun 18, 2017 at 5:31 AM, Eli Zaretskii <e...@gnu.org> wrote:
> > From: Orgad Shaneh <org...@gmail.com>
> > Date: Sat, 17 Jun 2017 23:04:11 +0300
> > Cc: bug-make@gnu.org, Alexey Pavlov <alex...@gmail.com>
> >
> > +#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
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
