On Sat, Feb 25, 2012 at 2:57 AM, Andy Wingo <wi...@pobox.com> wrote: > Hello :) > > On Fri 24 Feb 2012 04:00, Nala Ginrut <nalagin...@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/ >
