Re: on_exit_reset fails to clear DSM-related exit actions - Mailing list pgsql-hackers

From Andres Freund
Subject Re: on_exit_reset fails to clear DSM-related exit actions
Date
Msg-id 20140307201725.GA28328@awork2.anarazel.de
Whole thread Raw
In response to Re: on_exit_reset fails to clear DSM-related exit actions  (Peter LaDow <petela@gocougs.wsu.edu>)
Responses Re: on_exit_reset fails to clear DSM-related exit actions  (Peter LaDow <petela@gocougs.wsu.edu>)
Re: on_exit_reset fails to clear DSM-related exit actions  (Peter LaDow <petela@gocougs.wsu.edu>)
List pgsql-hackers
On 2014-03-07 12:09:45 -0800, Peter LaDow wrote:
> On Friday, March 7, 2014, Andres Freund <andres@2ndquadrant.com> wrote:
> >
> > If the third party library is suitably careful it will only use fork()
> > and then exec() or _exit(), otherwise there are other things that'll be

> But that is not possible* in our case of trying to spawn an asynchronous
> backgound process.

Forking twice is ok as well, as long as you just use _exit() after the
fork. The thing is that you shouldn't run any nontrivial code in the
fork, as long as you're connected to the original environment (fd's,
memory mappings and so forth).

> > Both perl and glibc seem to do just that in system() btw...

> I don't know about Perl, but system is blocking. What if you don't want to
> wait for the child to exit?

Man. The point is that that the library code is carefully written to not
use exit() but _exit() after a fork failure, that's it.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Peter LaDow
Date:
Subject: Re: on_exit_reset fails to clear DSM-related exit actions
Next
From: Peter LaDow
Date:
Subject: Re: on_exit_reset fails to clear DSM-related exit actions