On Sun, May 19, 2019 at 9:26 PM Steve Kargl
<s...@troutmask.apl.washington.edu> wrote:
>
> On Sun, May 19, 2019 at 09:10:57PM +0300, Janne Blomqvist wrote:
> > On Sun, May 19, 2019 at 7:15 PM Steve Kargl
> > <s...@troutmask.apl.washington.edu> wrote:
> > >
> > > On Sun, May 19, 2019 at 01:40:59PM +0300, Janne Blomqvist wrote:
> > > >
> > > > +#if defined(HAVE_SIGACTION) && defined(HAVE_WAITPID)
> > > > + static bool sig_init_saved;
> > > > + bool sig_init = __atomic_load_n (&sig_init_saved,
> > > > __ATOMIC_RELAXED);
> > > > + if (!sig_init)
> > > > + {
> > > > + struct sigaction sa;
> > > > + sa.sa_handler = &sigchld_handler;
> > > > + sigemptyset(&sa.sa_mask);
> > > > + sa.sa_flags = SA_RESTART | SA_NOCLDSTOP;
> > > > + sigaction(SIGCHLD, &sa, 0);
> > > > + __atomic_store_n (&sig_init_saved, true, __ATOMIC_RELAXED);
> > > > + }
> > > > +#endif
> > >
> > > Where do the prototypes for __atomic_load_n and __atomic_store_n
> > > come from? On FreeBSD, it seems these are in stdatomic.h. Do
> > > we need a HAVE_ATOMIC to include the header?
> >
> > They are GCC atomic builtins, they are always available, no need to
> > include a header:
> > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
>
> Thanks for the clarification. OK for trunk.
Thanks, committed as r271384.
> > > On a slightly different note, the nonstandard SYSTEM intrinsic
> > > uses system(3) to execute a command. I believe that it will
> > > leave zombies/orphaned children if a process is interrupted.
> > > Perhap, SYSTEM should be reworked to use your EXECUTE_COMMAND_LINE.
> >
> > I believe any competent implementation of system() would wait for the
> > child process. Since system() is synchronous, it can do the waiting
> > inline without having to use a signal handler.
>
> I'll need to check. I recall that
>
> program foo
> call system("Something_that_takes_along_time_to_execute")
> end program foo
>
> gfortran -o foo foo.f90
>
> % foo
> ^C
>
> Results in termination of the parent foo, and
> Something_that_takes_along_time_to_execute is orphaned and
> continues to run. It would probably be better to deliver
> SIGKILL to child. I suppose that that is for another day.
I guess the expected behavior is that is the parent dies, the child
gets orphaned and thus re-parented to PID 1 (that is, init) which
takes care of wait()'ing for it so it's not left as a zombie when it
dies. Not sure it's possible to change this is a robust and portable
way. But if someone figures it out, we can think about it then.
--
Janne Blomqvist
