Re: Opportunistic GC

[Philipp Stephani <p.stephani2@gmail.com>]

Am Mo., 8. März 2021 um 16:53 Uhr schrieb Andrea Corallo via Emacs
development discussions. <emacs-devel@gnu.org>:
>
> Pip Cet <pipcet@gmail.com> writes:
>
> > On Mon, Mar 8, 2021 at 2:01 PM Andrea Corallo <akrl@sdf.org> wrote:
> >> Pip Cet <pipcet@gmail.com> writes:
> >>
> >> > On Mon, Mar 8, 2021 at 3:37 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> >> I've been running with the code below recently to try and see if
> >> >> opportunistic GC can be worth the trouble.
> >> >
> >> > Just a random idea: What if we exploit the fact most people have more
> >> > than one CPU core these days, garbage-collect in a separate fork()ed
> >> > process, then do only the sweeping in the main process?
> >>
> >> It's an interesting concept, I thought about something similar in the
> >> past but, I've two questions:
> >>
> >> Are we really sure that a non trivial process can long survive
> >> or work as expected after being forked?
> >
> > I believe that, on all systems where bash works, we can expect fork()
> > to behave.
>
> I also expect fork will work, I'm more wondering about interaction with
> sockets file descriptors or anything else in our codebase and/or in
> libraries we have loaded.
>
> I've read in the past this is an issue in practice in non trivial code
> and that, because the typical use of fork () nowadays is just to run
> afterward exec (), operating in the grey between the two was not really
> a good idea.  But I don't have the reference now and if you say it works
> I've no reasons not to trust you.

The restriction is that you can only call async-signal-safe functions
in subprocesses before exec. See e.g. the man page for fork on
GNU/Linux.