Re: GMAKE 3.81 vs GMAKE 4.2

[nikhil jain]

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 <address@hidden> 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 <address@hidden> 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.
>>
>>