On Sat, Feb 25, 2012 at 2:57 AM, Andy Wingo
<address@hidden> wrote:
Hello :)
On Fri 24 Feb 2012 04:00, Nala Ginrut <
address@hidden> 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?
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"?