Messages in this thread | | | Date | Sat, 09 Apr 2011 00:26:22 +0400 | From | Stas Sergeev <> | Subject | Re: [path][rfc] add PR_DETACH prctl command |
| |
08.04.2011 22:13, Bryan Donlan wrote: > I can't comment on the patch itself, but, if your application knows it > might have to daemonize after spinning up threads, why not simply > fork() immediately on startup, and have the parent simply wait forever > for either the child to die or for a daemonize signal from the child? > If done early enough it shouldn't tie up too much memory, and it > wouldn't require any of these invasive kernel changes. As an added > bonus, it's portable to all unixen :) Yes, thats almost always true. Except when you deal with the vendor-provided poorly-coded drivers and libs, where you get the drivers initialized only via the lib. And the initialization process must be finished before the boot-up can continue, but that's not the whole story: only the process that initialized that lib, can then work with it. And of course that lib creates a dozen of threads... OK, you've got the idea. :) But anyway. Yes, not everyone have to deal with such a nightmare, this is very rare. But people being confused by the fact that daemon() silently loses threads, are not rare. So I just wonder: even if the workaround is simple, why searching for the workaround at all? If you need 2 syscalls to detach from parent, and you loose the threads in a process, then why not to have a single call, that detaches without loosing threads? But in any case, I am mostly inclinced to leave that patch for my project only.
| |