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