On Sat, Feb 25, 2012 at 2:57 AM, Andy Wingo <wingo@pobox.com> wrote:

> Hello :)
>
> On Fri 24 Feb 2012 04:00, Nala Ginrut <nalaginrut@gmail.com> writes:
>
> > I think I could use pipes to handle some sub-process rather than do it
> > with fork manually. But I must create a daemon, it can't avoid to use
> > fork, will this circumstance cause problems if I use threads after it?
>
> Hummm.  Very good question.  I started to answer this, but ended up
> committing the hack I mailed before, then found this reply now.
>
> Basically, if you try to daemonize with fork, you would need to do it
> very early, before your program makes any threads.  In master, Guile now
> enforces that condition.
>
>
So, this suggestion implies primitive-fork would be kept?


> Note that the first time your program calls `sigaction', Guile spawns a
> thread to handle signals.  You'd need to fork before installing signal
> handlers.
>
>
Fortunately. ;-)


> Another thing to think about is libgc.  In the "master" branch, libgc
> itself can spawn threads -- for example, a thread for doing parallel
> marking.
>
> There is a tension here between making things work, and making them
> correct.  It is possible to get fork + threads mostly working on glibc
> platforms -- for example, we could restart signal-handling and finalizer
> threads in primitive-fork.  But it is not possible to make the use of
> `primitive-fork' correct, in general, in the presence of threads.
>
>
I think all I need primitive-fork is just to daemonize, and I can try to do
it in the very early.
Moreover, primitive-fork would be restricted to be used for daemon to
anybody.
Considering this point, why not add a "daemonize" proc instead of
"primitive-fork"?


> Cheers,
>
> Andy
> --
> http://wingolog.org/
>