Re: on_exit_reset fails to clear DSM-related exit actions

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Peter LaDow <petela(at)gocougs(dot)wsu(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: on_exit_reset fails to clear DSM-related exit actions
Date: 2014-03-07 20:17:25
Message-ID: 20140307201725.GA28328@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-03-07 12:09:45 -0800, Peter LaDow wrote:
> On Friday, March 7, 2014, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter LaDow 2014-03-07 20:51:33 Re: on_exit_reset fails to clear DSM-related exit actions
Previous Message Peter LaDow 2014-03-07 20:09:45 Re: on_exit_reset fails to clear DSM-related exit actions