From: Stas Sergeev <stsp@aknet.ru>
To: Bryan Donlan <bdonlan@gmail.com>
Cc: Linux kernel <linux-kernel@vger.kernel.org>,
Oleg Nesterov <oleg@redhat.com>
Subject: Re: [path][rfc] add PR_DETACH prctl command
Date: Sat, 09 Apr 2011 00:26:22 +0400 [thread overview]
Message-ID: <4D9F6F6E.6040107@aknet.ru> (raw)
In-Reply-To: <BANLkTinfOKf+aSKy+Rj+2+v42JeGuzzrNg@mail.gmail.com>
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.
next prev parent reply other threads:[~2011-04-08 20:27 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 13:50 [path][rfc] add PR_DETACH prctl command Stas Sergeev
2011-02-23 19:14 ` Oleg Nesterov
2011-02-23 20:35 ` Stas Sergeev
2011-02-24 13:29 ` Oleg Nesterov
2011-02-24 15:13 ` Stas Sergeev
2011-02-24 15:32 ` Oleg Nesterov
2011-03-31 16:10 ` Stas Sergeev
2011-03-31 17:02 ` Oleg Nesterov
2011-03-31 17:47 ` Stas Sergeev
2011-03-31 18:18 ` Oleg Nesterov
2011-03-31 20:58 ` Stas Sergeev
2011-04-02 13:55 ` Oleg Nesterov
2011-04-02 18:20 ` Stas Sergeev
2011-04-02 22:00 ` Stas Sergeev
2011-04-01 17:02 ` Stas Sergeev
2011-04-02 14:06 ` Oleg Nesterov
2011-04-04 14:34 ` Stas Sergeev
2011-04-04 16:03 ` Oleg Nesterov
2011-04-04 20:05 ` Stas Sergeev
2011-04-05 15:15 ` Oleg Nesterov
2011-04-05 16:25 ` Stas Sergeev
2011-04-05 16:45 ` Oleg Nesterov
2011-04-05 17:51 ` Stas Sergeev
2011-04-08 10:51 ` Stas Sergeev
2011-04-08 18:55 ` Oleg Nesterov
2011-04-08 20:16 ` Stas Sergeev
2011-04-11 11:15 ` Stas Sergeev
2011-04-19 14:44 ` [path][rfc] add PR_DETACH prctl command [1/3] Stas Sergeev
2011-04-19 14:50 ` [path][rfc] add PR_DETACH prctl command [2/3] Stas Sergeev
2011-04-19 14:54 ` [path][rfc] add PR_DETACH prctl command [3/3] Stas Sergeev
2011-04-19 14:58 ` Alan Cox
2011-04-19 15:08 ` Stas Sergeev
2011-04-19 15:54 ` Alan Cox
2011-04-19 16:13 ` Oleg Nesterov
2011-04-19 16:29 ` Oleg Nesterov
2011-04-19 16:54 ` Stas Sergeev
2011-04-19 17:20 ` Oleg Nesterov
2011-04-19 17:41 ` Stas Sergeev
2011-04-19 18:17 ` Oleg Nesterov
2011-04-19 16:19 ` Stas Sergeev
2011-04-20 13:12 ` [path][rfc] add PR_DETACH prctl command [1/2] Stas Sergeev
2011-04-20 13:14 ` [path][rfc] add PR_DETACH prctl command [2/2] Stas Sergeev
2011-04-20 16:50 ` Oleg Nesterov
2011-04-20 18:45 ` Stas Sergeev
2011-04-20 19:33 ` Oleg Nesterov
2011-04-20 20:35 ` Stas Sergeev
2011-04-21 20:00 ` Oleg Nesterov
2011-04-21 20:11 ` Stas Sergeev
2011-04-21 10:02 ` Stas Sergeev
2011-04-21 20:15 ` Oleg Nesterov
2011-04-21 20:32 ` Stas Sergeev
2011-04-08 18:13 ` [path][rfc] add PR_DETACH prctl command Bryan Donlan
2011-04-08 20:26 ` Stas Sergeev [this message]
2011-04-08 20:52 ` Bryan Donlan
2011-04-08 21:14 ` Stas Sergeev
2011-04-08 21:25 ` Bryan Donlan
2011-04-08 21:38 ` Stas Sergeev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D9F6F6E.6040107@aknet.ru \
--to=stsp@aknet.ru \
--cc=bdonlan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.