Hi Paul,
I am coming across a strange issue in gmake.
in Job.c there is a condition -
/* Now try a blocking wait for a remote child. */
pid = remote_status (&exit_code, &exit_sig, &coredump, 1);
this pid is coming as -1 and errorno set to 10 means no child.
But I had printed this -
DB (DB_JOBS, (_("Live child %p (%s) PID %s %s\n"),
c, c->file->name, pid2str (c->pid),
c->remote ? _(" (remote)") : ""));
And i see one child available.
Is there any race condition when running with -J option greater than 0.
I see this comment -
/* We have one less dead child to reap. As noted in
child_handler() above, this count is completely unimportant for
all modern, POSIX-y systems that support wait3() or waitpid().
The rest of this comment below applies only to early, broken
pre-POSIX systems. We keep the count only because... it's there...
The test and decrement are not atomic; if it is compiled into:
register = dead_children - 1;
dead_children = register;
a SIGCHLD could come between the two instructions.
child_handler increments dead_children.
The second instruction here would lose that increment. But the
only effect of dead_children being wrong is that we might wait
longer than necessary to reap a child, and lose some parallelism;
and we might print the "Waiting for unfinished jobs" message above
when not necessary. */
is this related ?
Please reply. It is really urgent.
On Tue, Dec 17, 2019 at 9:04 PM nikhil jain <jainnikhi...@gmail.com> wrote:
> Thank you Paul for the suggestions. Will think over them. Thanks for the
> help.
>
> On Tue, Dec 17, 2019 at 9:03 PM Paul Smith <psm...@gnu.org> wrote:
>
>> On Tue, 2019-12-17 at 20:44 +0530, nikhil jain wrote:
>> > No, I do not want to delete the object file before sending the target
>> > out. That's not how make should work or I should make it work.
>>
>> That is simply not true.
>>
>> In virtually all cases rebuilding a target will involve deleting the old
>> one in some fashion. Most reliable build systems will create the target
>> as
>> a different file then atomically rename it to its final name, so that if
>> the command is killed while the target is half-written it doesn't corrupt
>> the next build.
>>
>> It's absolutely fine if the recipe decides to delete the target explicitly
>> before starting to rebuild it and a great many recipes work exactly like
>> this. The old file will not be used anyway if the recipe fails, nor
>> should
>> you want it to be since it's known to be out of date!
>>
>> > It is issue with NFS stale mounts which seems to be resolved if we open
>> > the file again according to NFS specs (mentioned in another email).
>>
>> As I haven't seen the actual code you're using I can't say for sure but in
>> general I'm leery of adding extra overhead to every check of every target
>> to handle an obscure case that can't actually happen with standard make.
>>
>>
