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
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 |